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Abstract 


Using  relevant  best  practices  from  the  CMMI ®  (Capability  Maturity  Model'  Integration)  for  Ac¬ 
quisition  (CMMI-ACQ)  model,  this  primer  defines  effective  and  efficient  practices  for  acquisition 
projects.  These  best  practices  address  activities  that  include  monitoring  and  controlling  contrac¬ 
tors  and  suppliers  that  develop  products  and  services  and  deliver  services.  The  practices  in  this 
primer  provide  a  foundation  for  acquisition  process  discipline  and  rigor  that  enables  product  and 
service  development  and  service  delivery  to  be  repeatedly  executed  for  ultimate  acquisition  suc¬ 
cess. 

This  primer  can  be  used  by  projects  that  acquire  products  or  services  in  government  and  non¬ 
government  organizations  to  improve  acquisition  processes.  Selected  content  of  the  CMMI-ACQ 
model  is  used  in  this  primer  as  a  basis  for  helping  readers  unfamiliar  with  CMMI  to  begin  their 
process  improvement  journey.  After  using  this  primer,  most  organizations  will  want  to  implement 
the  CMMI-ACQ  model. 

This  primer  can  also  be  used  by  acquisition  organizations  that  manage  several  related  acquisition 
projects  (e.g.,  product  centers,  acquisition  commands)  to  establish  an  acquisition  process  im¬ 
provement  program.  However,  organizations  at  that  level  should  consider  using  the  CMMI-ACQ 
model  instead  because  it  includes  organizational  process  management  practices. 
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1  Introduction 


The  CMMf-ACQ  Primer  is  a  stand-alone  guide  that  describes  best  practices  for  use  in  the  acqui¬ 
sition  of  products  and  services  and  prepares  users  for  implementing  the  CMMI  for  Acquisition 
(CMMf  -ACQ)  model1  for  process  improvement.  This  primer  focuses  on  efficient  and  effective 
acquisition  processes  and  practices  that  are  implemented  by  first-level  acquisition  projects,  such 
as  those  conducted  by  a  system  program  office  or  program  manager  in  the  Department  of  Defense 
(DoD).  The  information  contained  in  this  primer  can  also  be  used  by  organizations  that  manage 
multiple  programs  (e.g.,  product  centers,  acquisition  commands)  to  implement  process  improve¬ 
ment  activities;  although,  at  that  organizational  level,  the  CMMI -ACQ  model  is  more  beneficial 
(see  Section  1.3). 

1.1  PURPOSE  AND  OBJECTIVES 

Acquisition  projects  are  complex  because  they  are  directed  outward  toward  acquiring  products, 
systems,  services,  and  capabilities  to  meet  a  set  of  operational  expectations  and  directed  inward 
toward  ensuring  that  the  acquisition  process  is  conducted  with  discipline.  The  CMMI-ACQ  model 
incorporates  this  duality  by  recognizing  that  some  activities  are  under  the  direct  control  of  the 
acquisition  project,  while  others  involve  monitoring  or  facilitating  the  success  of  external  partners 
and  suppliers. 

System  development  projects  face  the  challenge  of  meeting  aggressive  performance,  cost,  and 
schedule  objectives.  At  the  same  time,  acquisition  leaders  work  to  create  a  flexible  environment 
for  acquisition  projects  while  drastically  decreasing  acquisition  cycle  times  and  improving  credi¬ 
bility.  Rising  levels  of  system  complexity;  increasing  software  contribution  to  overall  system 
functionality;  demands  for  agile,  adaptable  products;  and  shortened  delivery  timeframes  place 
stress  on  existing  acquisition  practices.  Congressional  and  DoD-level  guidance  emphasizes  soft¬ 
ware  acquisition  process  improvement,  including  the  measurement  of  process  performance. 

The  objective  of  the  CMMI-ACQ  model  is  to  influence  the  outcome  of  the  acquisition  process, 
delivering  the  right  capabilities  to  operational  users  on  schedule  and  at  predictable  costs  through 
the  disciplined  application  of  efficient  and  effective  acquisition  processes.  Applying  this  approach 
requires  renewed  dedication  to  defining,  implementing,  measuring,  and  maintaining  the  acquisi¬ 
tion  processes  fundamental  to  a  technically  sound  project. 

Acquisition  projects  perform  a  number  of  processes  to  achieve  success.  The  goals  and  practices 
for  these  processes  are  described  in  general  terms  to  support  the  numerous  variations  in  applica¬ 
tion  that  occur  in  different  acquisition  environments.  Because  variations  in  execution  are  at  the 
discretion  of  the  acquisition  project,  the  CMMI-ACQ  model  focuses  on  “what”  should  be  done 
not  “how”  it  is  done;  it  does  not  prescribe  specific  implementation  approaches. 


The  CMMI-ACQ,  VI. 2  model  is  a  collection  of  best  practices  that  is  generated  from  the  CMMI  VI. 2  Framework. 
This  collection  includes  acquisition  best  practices  from  government  and  industry  for  acquiring  products  and  ser¬ 
vices. 
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1.2  CMMI  TERMINOLOGY 


This  primer  uses  terminology  from  CMMI-ACQ,  which  groups  the  process  areas  into  the  follow¬ 
ing  process  area  categories: 

•  Process  Management  (i.e.,  Organizational  Management) 

•  Project  Management 

•  Support 

•  Acquisition 

The  Process  Management,  Project  Management,  and  Support  process  areas  are  part  of  the  CMMI 
Model  Foundation  (CMF)  and  are  common  to  all  CMMI  models.  This  fact  makes  it  convenient  to 
align  processes  between  the  acquirer  and  the  supplier  if  the  supplier  is  using  the  CMMI  for  De¬ 
velopment  (CMMI-DEV)  model.  The  Acquisition  process  areas  are  specific  to  the  CMMI-ACQ 
model.  This  primer  includes  selected  Project  Management  and  Support  process  areas  that  define 
the  requirements  for  managing  and  defining  processes  within  acquisition  and  all  of  the  Acquisi¬ 
tion  process  areas. 

The  Process  Management  process  areas  in  the  CMMI-ACQ  model  provide  details  on  how  to  de¬ 
fine  and  improve  processes  within  the  context  of  the  organization  in  which  the  acquisition  project 
resides.  The  CMMI-ACQ  model  also  contains  those  Project  Management  and  Support  process 
areas  considered  to  contain  practices  at  a  higher  level  of  maturity  than  those  contained  in  this  pri¬ 
mer.  For  more  information  about  Process  Management  and  high  maturity  process  areas,  see  the 
CMMI-ACQ  model  at  http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html. 


Project  Management 

Project  Planning  (PP) 

Project  Monitoringand  Control  (PMC) 

Integrated  Project  Management(IPM) 

Requirements  Management  (REQM) 

Risk  Management  (RSKM) 

Acquisition 

Solicitation  and  Supplier  Agreement  Development  (SSAD) 
Agreement  Management  (AM) 

Acquisition  Requirements  Development(ARD) 

Acquisition  Technical  Management  (ATM) 

Acquisition  Verification  (AVER) 

Acquisition  Validation  (AVAL) 

Support 

Configuration  Management(CM) 

Decision  Analysis  and  Resolution  (DAR) 

Measurementand  Analysis  (MA) 

Process  and  Product  Quality  Assurance  (PPQA) 

Figure  1:  Process  Areas  Covered  in  this  Primer 
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CMMI  terminology  should  be  understood  in  both  the  acquisition  and  process  improvement  con¬ 
texts.  For  example,  in  the  CMMI  Product  Suite,  the  following  terminology  is  important  to  under¬ 
stand: 

•  The  term  project  denotes  a  managed  set  of  interrelated  resources  that  delivers  one  or  more 
products  to  a  customer  or  end  user.  A  project  (or  program,  depending  on  local  interpretation) 
refers  to  the  entire  acquisition  project  or,  perhaps,  to  major  subsets  of  the  acquisition  project. 
The  scope  of  the  term  is  tailored  to  the  specific  acquisition. 

•  The  term  organization  is  typically  used  to  denote  an  administrative  structure  in  which  people 
collectively  manage  one  or  more  projects.  Projects  share  a  senior  manager  and  operate  under 
the  same  policies.  Examples  of  acquisition  organizations  include  larger  or  “super”  program 
offices,  product  centers,  acquisition  commands,  program  executive  officers,  and  ser¬ 
vice/component  acquisition  executives. 

•  The  term  work  product  is  any  artifact  produced  by  a  process. 

•  The  term  product  denotes  a  tangible  output  or  a  service  that  is  a  result  of  a  process  and  that  is 
intended  for  delivery  to  a  customer  or  end  user.  A  product  is  a  work  product  that  is  delivered 
to  the  customer.  The  term  system  is  not  used;  the  term  product  is  used  instead.  And  the  term 
product  includes  services. 

•  The  term  supplier  is  used  instead  of  the  term  contractor,  since  agreements  can  take  fonns 
other  than  contracts,  such  as  a  memorandum  of  agreement. 

•  The  term  supplier  agreement  is  used  instead  of  the  term  contract.  A  supplier  agreement  is  a 
documented  agreement  between  the  acquirer  and  supplier  (e.g.,  contract,  license,  or  memo¬ 
randum  of  agreement). 

Decide  how  these  terms  apply  in  your  environment. 

1.3  IMPROVING  PROCESSES  FOR  ACQUISITION 

Process  improvement  can  be  viewed  from  two  perspectives:  at  the  project  level  and  at  the  organi¬ 
zation  level.  Both  are  important  for  sustained  process  improvement  in  an  acquisition  organization. 

1.3.1  Project-Level  Process  Improvement 

Acquisition  projects  ensure  the  practices  they  perform  effectively  reduce  risks  associated  with 
common  management,  technical,  and  support  issues  that  arise  during  the  project.  The  specific 
practices  in  Section  2  and  the  generic  practices  in  Section  3  represent  the  project-level  practices 
that  can  be  used  to  identify  gaps  in  the  project’s  implementation  or  process-related  risks.  Careful 
use  of  selected  measures  can  help  gain  insight  into  the  effectiveness  of  project-level  process  im¬ 
plementation. 

In  addition,  higher  level  acquisition  organizations  with  multiple  projects  or  with  oversight  respon¬ 
sibility  can  use  these  practices  to  identify  areas  that  may  require  a  process  improvement  focus.  A 
project  that  has  well-defined  processes  has  a  greater  ability  to  deal  with  risk  and  complexity. 
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1.3.2  Organizational  Process  Improvement 

Process  improvement  at  the  organizational  level  creates  an  effective  environment  and  infrastruc¬ 
ture  that  allows  acquisition  projects  in  the  organization’s  span  of  control  a  greater  probability  to 
succeed.  When  a  project  has  clear  guidance,  starter  templates,  historical  data,  and  a  strong  process 
culture  at  the  organizational  level,  it  is  more  likely  to  sustain  effective  practices  and  ultimately 
achieve  its  objectives. 

Acquisition  organizations  that  manage  multiple  programs  (e.g.,  product  centers,  acquisition  com¬ 
mands,  program  executive  offices,  service/component  acquisition  organizations)  can  improve  by 
working  with  successful  projects  to  capture  success  stories;  measuring  the  effectiveness  of  proc¬ 
esses  across  the  projects  they  manage;  and  beginning  to  build  a  standard  set  of  acquisition  prac¬ 
tices,  proven  by  their  success  in  real  projects,  for  use  in  subsequent  projects.  Senior  leaders  can 
establish  an  infrastructure  and  strong  process  culture  that  rewards  projects  that  build  realistic 
plans  and  execute  according  to  those  plans. 

Acquisition  organizations  can  improve  both  the  capability  of  their  organizational  processes,  as 
well  as  the  capability  of  selected  project-level  processes  across  the  organization,  by  using  the 
CMMI-ACQ  model.  Process  areas  to  use  when  improving  organizational  capability  include  Or¬ 
ganizational  Process  Focus,  Organizational  Process  Definition,  and  Organizational  Training.  The 
CMMI-ACQ  model  is  available  at 

http://www.sei.cmu.edu/publications/documents/07.reports/07tr0 1 7.html . 
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2  Process  Areas 


The  process  areas  in  this  section  are  from  the  CMMI-ACQ  model.  They  represent  a  minimal  set 
of  processes  that  cover  the  best  practices  needed  to  successfully  address  the  entire  acquisition  li¬ 
fecycle.  Each  acquisition  project  operates  within  a  unique  environment  that  influences  the  defini¬ 
tion  of  its  lifecycle.  The  acquisition  lifecycle,  especially  as  it  applies  to  upgrades  and  modifica¬ 
tions,  may  restart  after  a  cycle  is  initiated  and  partially  completed.  For  example,  acquisition  of  a 
major  upgrade  may  be  initiated  for  a  product  or  service  that  has  already  been  developed,  fielded, 
and  placed  into  operation.  In  these  cases,  the  deployment  of  CMMI-ACQ  could  result  in  the  up¬ 
grade  acquisition  being  considered  a  new  acquisition  lifecycle,  with  complex  implementation  re¬ 
quirements  of  its  own  that  may  impact  another  acquisition  lifecycle  already  underway.  Or,  in  oth¬ 
er  cases,  the  acquisition  lifecycle  may  continue  throughout  the  product’s  lifecycle,  including 
disposal. 

In  the  process  areas  listed  in  this  section,  goals  are  shown  in  bold-faced  text.  Below  each  goal  are 
numbered  statements  that  reflect  the  recommended  practices.  For  more  extensive  treatment  of 
these  goals  and  practices,  see  the  CMMI-ACQ  model,  which  also  includes  subpractices,  typical 
work  products,  typical  supplier  deliverables,  and  references  to  other  related  process  areas. 

2.1  PROJECT  MANAGEMENT  PROCESS  AREAS 

Project  Management  process  areas  cover  project  management  activities  related  to  planning,  moni¬ 
toring,  and  controlling  projects.  In  addition,  they  include  activities  that  ensure  the  products  or  ser¬ 
vices  acquired  can  be  transitioned  into  operational  use  and  maintained  during  the  operational  life 
of  the  product  or  service. 
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Project  Planning  (PP) 


The  purpose  of  Project  Planning  is  to  establish  and  maintain  plans  that  define  project  activities. 

Project  planning  starts  by  setting  the  acquisition  strategy  and  follows  with  planning  the 
acquisition  process  in  ever-increasing  levels  of  detail.  The  resulting  plans  should  be  reviewed  for 
consistency  with  the  overall  acquisition  plans.  The  acquirer ’s  and  supplier 's  project  planning 
processes  are  continuously  conducted,  as  the  plans  evolve  to  meet  the  project 's  needs. 

If  an  existing  product  is  to  be  replaced  as  part  of  the  acquisition,  the  acquirer  may  be 
required  to  consider  transition  from  operation  and  the  disposal  of  the  existing  product  as  part 
of  the  planning  for  executing  the  new  product.  Any  such  transition  activities  should  be 
included  in  the  project  plan  as  well  as  provisions  for  accommodating  such  specialized 
requirements. 

1.  Estimates  of  project  planning  parameters  are  established  and  maintained. 

1 . 1  Establish  and  maintain  the  acquisition  strategy. 

The  acquisition  strategy  relates  the  acquisition  objectives ,  constraints,  availability  of 
assets  and  technologies,  consideration  of  acquisition  methods,  potential  supplier 
agreement  types  and  terms,  accommodation  of  end  user  considerations,  consideration  of 
risk,  and  support  for  the  project  over  its  lifecycle. 

1.2  Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate  the  scope  of  the 
project. 

The  WBS  should  list  the  tasks  for  the  entire  project,  including  activities  performed  by  the 
acquisition  project  as  well  as  suppliers  and  other  stakeholders  (e.g.,  test  community, 
operational  users).  Include  all  these  parties  to  ensure  the  planning  effort  includes  the 
scope  for  the  entire  acquisition. 

1.3  Establish  and  maintain  estimates  of  work  product  and  task  attributes. 

Estimates  of  the  attributes  of  the  work  products  and  tasks  are  used  to  bound  the  budget 
and  schedule. 

1.4  Define  project  lifecycle  phases  upon  which  to  scope  the  planning  effort. 

Typical  lifecycle  choices  include  single-step  or  evolutionary  incremental.  Include  in 
planning  the  entire  known  lifecycle  from  user  needs  through  initial  and  subsequent 
upgrades.  The  acquisition  organization  should  consider  the  full  collection  of  supplier 
agreements  within  a  project  context  to  ensure  an  integrated  approach  rather  than  an 
approach  that  deals  with  activities  individually.  An  integrated  approach  supports  project 
planning  activities  on  occasions  when  some  elements  of  the  acquisition  or  lifecycle  may 
be  out  of  the  control  of  the  acquisition  organization. 

1.5  Estimate  the  project’s  effort  and  cost  for  work  products  and  tasks. 

In  addition  to  creating  an  estimate  of  project  work  products,  the  acquisition  organization 
should  have  its  estimate  independently  reviewed  by  those  external  to  the  project  to 
validate  the  project  estimate.  Be  sure  to  include  the  effort  and  cost  supporting  execution 
of  the  acquisition  processes  as  well  as  the  effort  and  cost  supporting  development  of  the 
product  or  service.  Estimates  of  the  effort  and  cost  of  work  products  and  tasks  are  used  to 
establish  the  overall  project  budget  and  schedule. 
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2.  A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the  project. 

2. 1  Establish  and  maintain  the  project’s  budget  and  schedule. 

The  acquisition  project ’s  budget  and  schedule  should  be  created  and  maintained  for  the 
duration  of  the  project.  The  budget  and  schedule  should  include  lifecycle-related 
activities  of  the  acquisition  organization  itself  the  supplier,  supporting  organizations, 
suppliers  that  support  the  acquisition  organization,  and  other  stakeholders. 

2.2  Identify  and  analyze  project  risks. 

Identify  risks  from  multiple  perspectives  (e.g.,  acquisition,  technical,  management, 
operational,  supplier,  support,  and  user)  to  ensure  all  project  risks  are  considered  in 
planning  activities. 

2.3  Plan  for  the  management  of  project  data. 

Consider  how  data  will  be  shared  across  all  relevant  stakeholders,  including  informal 
data  as  well  as  formal  project  data  and  plans.  Create  plans  for  managing  data  within 
integrated  teams  and  the  infrastructure  required  to  manage  data  among  the  supplier, 
operational  users,  and  other  relevant  stakeholders.  Decide  which  project  data  and  plans 
require  version  control  or  more  stringent  configuration  control  and  establish 
mechanisms  to  ensure  project  data  is  controlled.  Consider  the  implications  of  controlling 
access  to  classified  information  and  sensitive  but  unclassified  information  (e.g., 
proprietary,  export  controlled,  and  source  selection  sensitive  information)  and  other 
access-controlled  data. 

2.4  Plan  for  necessary  resources  to  perform  the  project. 

Plan  the  resources  required  for  the  acquisition  project  as  well  as  tools  and  infrastructure 
required  during  the  life  of  the  project.  Include  resource  planning  for  integration  and  test 
facilities. 

2.5  Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

Plan  for  knowledge  and  skills  required  by  the  project  team  to  perform  their  tasks. 
Knowledge  and  skill  requirements  can  be  derived  from  project  risks.  For  example,  if  the 
project  team  is  acquiring  a  software-intensive  product,  ensure  expertise  in  systems  and 
software  engineering  exists  on  the  project  team  or  provide  training  for  the  project  team 
in  these  areas.  Include  orientation  and  training  for  the  project  team  and  stakeholders  in 
acquisition  practices  and  the  domain  knowledge  recpdred  to  execute  the  project. 

2.6  Plan  the  involvement  of  identified  stakeholders. 

Stakeholders  can  include  operational  users  and  project  participants  from  test  or  other 
support  communities  as  well  as  potential  suppliers.  When  acquiring  products  or  services 
that  must  interoperate  with  other  products  or  services,  plan  for  the  involvement  of 
stakeholders  from  other  projects  or  communities  to  ensure  the  delivered  product  or 
service  can  perform  as  required  in  its  intended  environment. 

2.7  Plan  transition  to  operations  and  support. 
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The  acquisition  project  is  responsible  for  ensuring  the  acquired  products  not  only  meet 
specified  requirements  (see  the  Acquisition  Technical  Management  process  area)  and 
can  be  used  in  the  intended  environment  (see  the  Acquisition  Validation  process  area) 
but  also  that  they  can  be  transitioned  into  operational  use  to  achieve  the  users  ’  desired 
mission  capabilities  and  can  be  maintained  and  sustained  over  their  intended  lifecycles. 
The  acquisition  project  is  responsible  for  ensuring  reasonable  planning  for  transition 
into  operations  is  conducted,  clear  transition  criteria  exist  and  are  agreed  to  by  relevant 
stakeholders,  and  planning  is  completed  for  product  maintenance  and  support  of 
products  after  they  become  operational.  These  plans  include  reasonable  accommodation 
for  known  and  potential  evolution  of products  and  their  eventual  removal  from 
operational  use. 

Planning  for  transition  includes  establishing  the  strategy  for  support  (e.g.,  source  of 
repair)  through  organic  support  infrastructures,  supplier  logistics  support,  or  other 
sources.  It  can  also  include  defining  the  levels  of  support  to  be  established  (e.g., 
organization,  intermediate,  and  depot).  The  strategy  is  important  because  it  drives  most 
of  the  other  transition  planning  activities  as  well  as  product  design  considerations. 
Planning  includes  identifying  and  providing  for  initial  spares,  operational  and  support 
training  capabilities,  facilities,  etc.  Eventual  disposal  of  the  product  should  also  be 
considered  as  well  as  disposal  of  existing  products  to  be  replaced. 

The  roles  and  responsibilities  of  the  acquirer,  supplier,  and  user  should  be  defined  for 
lifecycle  support  of  the  product.  Explicitly  identifying  organizational  responsibility  for 
support  (i.e.,  level  1  maintenance)  and  for  enhancements  (i.e.,  level  2  maintenance) 
ensures  that  relevant  stakeholders  are  involved  early  in  the  acquisition  project ’s 
planning  processes. 

Responsibility  for  capability  enhancements  during  the  support  phase  should  be  assigned. 
Criteria  used  to  support  the  assignment  of  responsibilities  should  include  the  magnitude 
and  complexity  of  the  envisioned  change,  the  domain  knowledge  and  experience 
required,  and  the  acquisition  expertise  required. 

2.8  Establish  and  maintain  the  overall  project  plan. 

The  overall  project  plan  can  take  on  many  forms  and  may  even  be  found  in  multiple 
plans,  such  as  the  acquisition  strategy,  single  acquisition  management  plan,  program 
management  plan,  lifecycle  management  plan,  and  systems  engineering  plan. 

Regardless  of  its  form,  the  plan  or  plans  should  address  the  acquisition  strategy  as  well 
as  the  cradle-to-grave  considerations  for  the  project  and  product  to  be  acquired. 

3.  Commitments  to  the  project  plan  are  established  and  maintained. 

3.1  Review  all  plans  that  affect  the  project  to  understand  project  commitments. 

The  project  may  have  a  hierarchy  of  plans  (e.g.,  risk  management  plan,  systems 
engineering  plan,  and  requirements  management  plan) .  In  addition,  stakeholder  plans 
(e.g.,  operational,  test,  support,  and  supplier  plans)  should  be  reviewed  to  ensure 
consistency  among  all  project  participants. 

3.2  Adjust  the  project  plan  to  reconcile  available  and  estimated  resources. 

Wlien  available  resources  (e.g.,  personnel,  facilities,  stakeholders,  schedule,  and  funding) 
are  inadequate  to  accomplish  the  project,  consider  de-scoping  the  effort  to  match 
available  resources.  When  de-scoping  is  not  feasible,  identify  and  mitigate  these  risks. 

3.3  Obtain  commitment  from  relevant  stakeholders  responsible  for  performing  and 
supporting  plan  execution. 
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Major  project  planning  should  be  coordinated  with  stakeholders  and  the  resulting  plans 
should  be  approved  by  them. 
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Project  Monitoring  and  Control  (PMC) 


The  purpose  of  Project  Monitoring  and  Control  is  to  provide  an  understanding  of  the  project’s 
progress  so  that  appropriate  corrective  actions  can  be  taken  when  the  project’s  performance  devi¬ 
ates  significantly  from  the  plan. 

Project  monitoring  and  control  functions  are  directed  within  the  acquisition  project  early  in  the 
process  as  acquisition  planning  is  performed  and  the  strategy  is  defined.  As  the  acquisition 
project  unfolds,  monitoring  and  controlling  are  essential  to  ensuring  that  appropriate  resources 
are  being  applied  and  that  acquisition  activities  are  progressing  according  to  plan.  The  Project 
Monitoring  and  Control  process  area  involves  establishing  the  planned  internal  activities  and 
schedule  for  completion  and  then  monitoring  the  status  of  these  activities  and  work  product 
completions  through  measurement  and  analysis  (i.e.,  metrics).  It  is  important  that  the  acquisition 
project  has  internal  processes,  plans,  and  work  products  that  are  monitored  for  satisfactory 
completion  and  progress. 

Included  in  those  internal  items  monitored  should  be  work  product  completion  (e.g., 
specifications,  plans,  and  request  for  proposal  components),  staffing  levels  and  qualifications 
applied,  project  performance  objectives  and  thresholds,  infrastructure  readiness  (e.g.,  tools  and 
networks)  and  other  activities  and  products  included  in  project  planning.  Project  risk 
identification  and  mitigation  should  also  be  monitored  for  status. 

After  one  or  more  suppliers  are  selected  and  agreements  are  established,  the  role  of  monitoring 
and  control  becomes  twofold:  (1)  the  acquirer  continues  to  monitor  and  control  its  activities  and 
work  products,  (2)  at  the  same  time,  the  acquirer  monitors  and  controls  the  progress  and 
performance  of  supplier  activities  that  affect  the  overall  project  plan. 

1.  Actual  performance  and  progress  of  the  project  are  monitored  against  the  project 
plan. 

1 . 1  Monitor  actual  values  of  project  planning  parameters  against  the  project  plan. 

Monitoring  schedule,  budget,  and  acquisition  activity  progress  should  begin  as  soon  as  a 
project  plan  is  established. 

1.2  Monitor  commitments  against  those  identified  in  the  project  plan. 

Commitments  for  resources  that  result  in  expenditures  (e.g.,  issued  purchase  orders  and 
completed  deliverables  that  have  been  accepted)  should  be  tracked  when  incurred,  even 
prior  to  formal  payment,  to  ensure  that  future  financial  and  legal  obligations  are 
accounted  for  as  soon  as  they  are  incurred. 

1.3  Monitor  risks  against  those  identified  in  the  project  plan. 

The  acquisition  project  should  manage  risks  independent  of  the  supplier 's  risk 
management  procedures.  Many  risks  are  the  responsibility  of  the  acquisition  project  and 
may  include  sensitive  information  that  should  not  be  shared  with  the  supplier  (e.g., 
source  selection  sensitive,  re-competition,  and  internal  staffing  information). 

1.4  Monitor  the  management  of  project  data  against  the  project  plan. 

1.5  Monitor  stakeholder  involvement  against  the  project  plan. 

1.6  Periodically  review  the  project's  progress,  performance,  and  issues. 

1.7  Review  the  project’s  accomplishments  and  results  at  selected  project  milestones. 
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1.8  Monitor  transition  to  operations  and  support. 

The  acquirer  monitors  and  controls  the  transition  of  the  accepted  product  or  service 
against  the  plan  for  transition  to  operations  and  support.  Readiness  is  evaluated 
throughout  the  acquisition  lifecycle  based  on  transition  criteria.  Using  the  previously 
defined  transition  criteria,  objectively  evaluate  the  products  ’  readiness  for  transition. 

As  a  result  of  analysis,  transition  activities  and  actions  may  be  required  of  the  acquisition 
project,  supplier,  user,  or  support  organization.  The  analysis  may  also  identify  areas  for 
improvement  in  future  transition  activities. 

2.  Corrective  actions  are  managed  to  closure  when  the  project’s  performance  or  results 
deviate  significantly  from  the  plan. 

2. 1  Collect  and  analyze  issues  and  determine  corrective  actions  necessary  to  address 
them. 

Corrective  action  is  taken  for  both  acquirer  deviations  and  when  supplier  execution  does 
not  align  with  project  planning  (e.g.,  milestones  and  work  product  date  slippages). 

Many  issues  and  corrective  actions  are  the  sole  responsibility  of  the  acquirer  and  may 
include  information  that  should  not  be  shared  with  the  supplier  (e.g.,  source  selection 
sensitive,  re-competition,  and  internal  staffing  information). 

2.2  Take  corrective  action  on  identified  issues. 

Corrective  action  should  be  applied  when  execution  does  not  match  project  planning 
(e.g.,  internal  staffing,  project  plan  completion  dates,  draft  and  final  solicitation,  and 
supplier  agreement  award  milestone  dates). 

2.3  Manage  corrective  actions  to  closure. 

If  a  corrective  action  is  required  to  resolve  variances  from  project  plans,  these  actions 
should  be  defined  and  tracked  to  closure. 
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Integrated  Project  Management  (IPM) 


The  purpose  of  Integrated  Project  Management  is  to  establish  and  manage  the  project  and  the  in¬ 
volvement  of  the  relevant  stakeholders  according  to  an  integrated  and  defined  process  that  is  tai¬ 
lored  from  the  organization’s  set  of  standard  processes. 

Integrated  Project  Management  involves  establishing  project  management  processes  consistent 
with  and  tailored  from  the  organization 's  standard  processes.  It  includes  higher  level  acquisition 
guidance,  regulations,  instructions,  and  local  practices  established  to  be  used  across  various 
projects  in  the  local  organization.  Establishing  an  integrated  project  management  process  that 
incorporates  and  involves  relevant  stakeholders  (e.g.,  executive  level  acquisition  offices,  users, 
test  organizations,  developers,  and  associated  government  support  organizations)  is  critical  to  the 
success  of  the  project.  This  defined  project  management  process  is  typically  defined  in  an  overall 
project  management  plan  or  equivalent  document. 

The  integrated  project  management  process  needs  to  involve  and  integrate  all  relevant 
acquisition,  development,  support,  and  operational  activities.  Depending  on  the  size  of  the 
project,  the  size  of  the  coordination  efforts  can  be  significant. 

Formal  interfaces  among  project  stakeholders  take  the  form  of  memorandums  of  understanding 
(MOUs),  memorandums  of  agreements  (MOAs),  contractual  commitments,  associate  supplier 
agreements,  and  similar  documents,  depending  on  the  nature  of  the  interfaces  and  involved 
stakeholders. 

1.  The  project  is  conducted  using  a  defined  process  tailored  from  the  organization’s  set 
of  standard  processes. 

It  is  possible  that  the  organization  has  not  established  a  standard  set  of processes.  If  so,  the 
project  should  define  its  own  processes  appropriate  to  its  needs. 

1.1  Establish  and  maintain  the  project’s  defined  process  from  project  startup  through  the 
life  of  the  project. 

Often,  the  defined  process  for  a  project  is  developed  by  tailoring  and  integrating  higher 
level  organizational  guidance.  For  example,  guidance  in  the  Defense  Acquisition 
Guidebook  (http://akss.dau.mil/dag/)  in  conjunction  with  lower  level  guidance  at  the 
service,  component,  or  other  level,  would  be  used  by  a  project  to  establish  the  process  to 
be  used  to  acquire  the  project ’s  unique  product  or  sendee.  Where  no  organizational 
process  exists,  the  project  develops  the  defined  processes  itself. 

The  project 's  defined  process  is  driven  by  the  acquisition  strategy.  The  acquirer ’s  defined 
process  is  affected,  for  example,  by  whether  the  acquisition  strategy  includes  introducing 
a  new  technology  to  the  organization  or  consolidating  acquired  products  or  services 
currently  in  use  by  the  acquirer. 

1.2  Use  organizational  process  assets  and  the  measurement  repository  for  estimating  and 
planning  project’s  activities. 

When  available,  use  the  results  of  previous  planning  and  execution  activities  as 
predictors  of  the  relative  scope  and  size  of  the  effort  being  estimated  for  the  acquisition. 

1.3  Establish  and  maintain  the  project’s  work  environment  based  on  the  organization’s 
work  environment  standards. 


12  |  CMU/SEI-2008-TR-010 


The  supplier ’s  work  environment  should  be  compatible  with  the  acquirer ’s  work 
environment  to  enable  efficient  and  effective  transfer  of  work  products. 

1.4  Integrate  the  project  plan  and  other  plans  that  affect  the  project  to  describe  the 
project’s  defined  process. 

Tiered  plans  are  often  effective  for  large  projects. 

1.5  Manage  the  project  using  the  project  plan,  other  plans  that  affect  the  project,  and  the 
project’s  defined  process. 

1.6  Establish  and  maintain  integrated  teams. 

One  of  the  best  ways  to  ensure  coordination  and  collaboration  with  relevant  stakeholders 
(specific  goal  2  of  this  process  area)  is  to  include  them  on  an  integrated  team.  For 
projects  within  a  system  of  systems  framework,  the  most  important  integrated  team  may 
include  stakeholders  representing  other  systems  as  members. 

1.7  Contribute  work  products,  measures,  and  documented  experiences  to  organizational 
process  assets. 

If  a  repository  of  information  from  previous  similar  proj  ects  exists  at  the  start  of  the 
project,  consider  retaining  the  project’s  estimates  and  actual  results  for  use  in  estimating 
future  projects. 

2.  Coordination  and  collaboration  between  the  project  and  relevant  stakeholders  are 
conducted. 

2. 1  Manage  the  involvement  of  relevant  stakeholders  in  the  project. 

The  supplier  agreement  provides  the  basis  for  managing  supplier  involvement  in  the 
project.  Supplier  agreements  (e.g.,  interagency  and  intercompany  agreements, 
memorandums  of  understanding,  and  memorandums  of  agreement)  that  the  acquirer 
makes  with  stakeholder  organizations,  which  may  be  product  or  service  providers  or 
recipients,  provide  the  basis  for  their  involvement.  These  agreements  are  particularly 
important  when  the  acquirer ’s  project  produces  a  system  that  must  be  integrated  into  a 
larger  system  of  systems. 

2.2  Participate  with  relevant  stakeholders  to  identify,  negotiate,  and  track  critical 
dependencies. 

Stakeholder  activities  that  include  dependencies  critical  to  the  project  should  be 
negotiated  with  the  stakeholders  to  obtain  commitment  to  perform.  The  critical 
dependencies  should  be  identified  in  the  project  plan  so  those  activities  can  be  monitored 
and  controlled  relative  to  their  dependent  activities. 

2.3  Resolve  issues  with  relevant  stakeholders. 
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Requirements  Management  (REQM) 


The  purpose  of  Requirements  Management  is  to  manage  the  requirements  of  the  project's  products 
and  product  components  and  to  identify  inconsistencies  between  those  requirements  and  the  pro¬ 
ject's  plans  and  work  products. 

Requirements  management  processes  manage  all  requirements  received  or  generated  by  the 
project,  including  both  technical  and  nontechnical  requirements  as  well  as  requirements  levied  on 
the  project  by  the  organization.  Requirements  management  is  applied  to  the  requirements  that  are 
received  from  the  acquisition  requirements  development  process.  Requirements  management 
includes  the  direct  management  of  acquirer-controlled  customer  and  contractual  requirements 
(see  the  Acquisition  Requirements  Development  process  area)  and  oversight  of  supplier 
requirements  management.  Requirements  are  managed  and  maintained  with  discipline  so  that 
changes  are  not  executed  without  recognizing  the  impact  to  the  project. 

Requirements  management  does  not  end  with  the  selection  of  a  supplier  and  an  award.  The 
acquisition  project  continues  to  manage  high-level  requirements,  including  changes,  while  the 
selected  supplier  manages  the  lower  level  product  and  product  component  requirements. 

1.  Requirements  are  managed  and  inconsistencies  with  project  plans  and  work  prod¬ 
ucts  are  identified. 

1 . 1  Develop  an  understanding  with  requirements  providers  on  the  meaning  of 
requirements. 

The  acquirer  should  identify  “authorized”  requirements  providers  and  an  approved  path 
by  which  requirements  are  provided  to  the  supplier.  This  identification  prevents  suppliers 
from  receiving  requirements  changes  from  unauthorized  sources  that  are  outside  the  flow 
of  the  acquirer 's  established  requirements  management  process. 

1.2  Obtain  commitment  to  requirements  from  project  participants. 

Commitment  to  the  requirements  by  project  participants  includes  having  coordinated  and 
approved  documents  that  define  requirements.  Changes  to  requirements  may  lead  to 
changes  in  supplier  agreements.  These  changes  must  be  agreed  on  by  the  acquirer  and 
supplier  after  appropriate  negotiations. 

1.3  Manage  changes  to  requirements  as  they  evolve  during  the  project. 

Each  change  to  a  controlled  requirement  should  be  assessed  for  impact  to  the  project ’s 
performance,  cost,  and  schedule  baselines  and  to  project  risk.  The  existing  cost, 
schedule,  and  performance  baselines  should  be  changed,  as  required,  to  accommodate 
the  requirements  change.  If  contractual  requirements  defined  in  the  supplier  agreement 
are  affected  by  the  changes,  the  supplier  agreement  also  must  be  aligned  with  these 
changes. 

1.4  Maintain  bidirectional  traceability  among  requirements  and  work  products. 

When  requirements  are  managed  well,  traceability  can  be  established  from  a  source 
requirement  to  its  lower  level  requirements  and  from  those  lower  level  requirements  back 
to  their  source  requirements.  Such  bidirectional  traceability  helps  determine  whether  all 
source  requirements  have  been  completely  addressed  and  whether  all  lower  level 
requirements  can  be  traced  to  a  valid  source. 
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Requirements  traceability  can  also  cover  relationships  to  other  entities,  such  as 
intermediate  and  final  work  products,  changes  in  design  documentation,  and  test  plans. 
Traceability  can  cover  horizontal  relationships  (such  as  across  interfaces)  as  well  as 
vertical  relationships.  Traceability  is  particularly  needed  in  conducting  the  impact 
assessment  of  requirements  changes  on  project  activities  and  work  products. 

The  supplier  maintains  comprehensive  bidirectional  traceability  to  requirements  defined 
in  the  supplier  agreement  by  the  acquirer,  and  the  acquirer  verifies  that  traceability.  The 
acquirer  maintains  bidirectional  traceability  between  customer  requirements  and 
contractual  requirements. 

1.5  Identify  inconsistencies  between  project  plans  and  work  products  and  requirements. 
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Risk  Management  (RSKM) 


The  purpose  of  Risk  Management  is  to  identify  potential  problems  before  they  occur,  so  that  risk¬ 
handling  activities  may  be  planned  and  invoked  as  needed  across  the  life  of  the  product  or  project 
to  mitigate  adverse  impacts  on  achieving  objectives. 

Risk  identification  and  estimation  of probability  of  occurrence  and  impact,  particularly  for  those 
risks  involved  in  meeting  performance  recjuirements,  schedules,  and  cost  targets,  largely 
determine  the  acquisition  strategy.  The  acquirer  has  a  dual  role:  (1)  Assess  and  manage  overall 
project  risks  for  the  duration  of  the  project,  and  (2)  Assess  and  manage  risks  associated  with  the 
performance  of  the  supplier.  As  the  acquisition  progresses  to  the  selection  of  a  supplier,  the  risk 
specific  to  the  supplier’s  technical  and  management  approach  then  becomes  important  to  the 
success  of  the  acquisition. 

The  particular  risks  associated  with  integrated  teams  should  be  considered,  such  as  risks 
associated  with  loss  of  inter-  or  intra-team  coordination. 

1.  Preparation  for  risk  management  is  conducted. 

1 . 1  Determine  risk  sources  and  categories. 

Acquisition  organizations  should  initially  identify  and  categorize  risks  and  risk  sources 
for  the  project  and  refine  those  risks  and  categories  over  time  (e.g.,  schedule,  cost, 
supplier  execution,  technology  readiness,  and  issues  outside  control  of  acquisition 
organization). 

1.2  Define  parameters  used  to  analyze  and  categorize  risks  and  to  control  the  risk 
management  effort. 

Acquisition  organizations  should  document  the  parameters  used  to  analyze  and 
categorize  risks  so  that  they  are  available  throughout  the  project  for  reference  when 
circumstances  change  over  time.  In  this  way,  risks  can  easily  be  re-categorized  and 
analyzed  relative  to  the  original  information  when  changes  occur. 

1.3  Establish  and  maintain  the  strategy  to  be  used  for  risk  management. 

2.  Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

2. 1  Identify  and  document  risks. 

2.2  Evaluate  and  categorize  each  identified  risk  using  defined  risk  categories  and 
parameters,  and  determine  its  relative  priority. 

3.  Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse  impacts  on 
achieving  objectives. 

3.1  Develop  a  risk  mitigation  plan  for  the  most  important  risks  to  the  project  as  defined 
by  the  risk  management  strategy. 

3.2  Monitor  the  status  of  each  risk  periodically  and  implement  the  risk  mitigation  plan,  as 
appropriate. 

Risks  should  be  continually  monitored  and,  when  warranted,  the  mitigation  plan  should 
be  adjusted  to  adapt  for  change.  When  the  situation  requires  action,  mitigation  actions 
should  be  executed  promptly  based  on  the  mitigation  plan. 
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2.2  ACQUISITION  PROCESS  AREAS 


The  acquisition  process  areas  establish  a  consistent  set  of  requirements  and  agreements  that  are 
derived  from  stakeholder  needs  and  operational  capability  statements  so  that  work  products  de¬ 
veloped  internally  by  the  acquirer  and  work  products  and  delivered  products  and  services  from  the 
suppliers  are  proven  to  successfully  satisfy  end  user  needs  and  provide  operational  capabilities. 
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Solicitation  and  Supplier  Agreement  Development  (SSAD) 


The  purpose  of  Solicitation  and  Supplier  Agreement  Development  (SSAD)  is  to  prepare  a  solicita¬ 
tion  package,  select  one  or  more  suppliers  to  deliver  the  product  or  service,  and  establish  and 
maintain  the  supplier  agreement. 

The  solicitation  must  comply  with  applicable  federal,  departmental,  and  service  acquisition 
regulations  and  policies.  The  solicitation  should  address  activities  appropriate  to  the  product 
domain  or  acquisition  environment  (e.g.,  supplier  process  evaluations;  operational  safety, 
suitability,  and  effectiveness;  certifications;  architecture  evaluations;  and  interoperability).  The 
representatives  responsible  for  these  activities  within  the  project  or  stakeholder  organizations 
should  be  consulted  for  proper  inclusion  of  those  activities  into  the  solicitation  and  supplier 
agreement  development  process.  The  solicitation  practices  apply  equally  to  initial  supplier 
agreement  actions  and  subsequent  change  orders,  task  orders,  etc. 

The  Solicitation  and  Supplier  Agreement  Development  process  area  creates  a  proactive 
environment  that  enables  the  acquirer  to  initialize  the  relationship  with  the  supplier  for  the 
successful  execution  of  the  project.  It  encourages  creation  of  a  supplier  agreement  that  allows  the 
acquirer  to  execute  its  management  of  supplier  activities  using  other  process  areas,  such  as 
Agreement  Management  and  Acquisition  Technical  Management.  This  encouragement  may 
include  levying  a  requirement  on  the  supplier  to  create  a  project  plan  that  will  successfully 
execute  the  supplier  agreement,  to  define  and  execute  the  processes  needed  to  achieve  success, 
and  to  commit  to  executing  the  plan  as  it  evolves  during  supplier  agreement  execution. 

The  Solicitation  and  Supplier  Agreement  Development  process  area  involves  planning  for  and 
performing  the  practices  necessary  to  develop  and  issue  a  solicitation  package,  preparing  for  the 
evaluation  of  responses,  conducting  an  evaluation,  conducting  supporting  negotiations,  and 
establishing  and  maintaining  the  supplier  agreement. 

1.  Preparation  for  solicitation  and  supplier  agreement  development  is  performed. 

1 . 1  Identify  and  qualify  potential  suppliers. 

1.2  Establish  and  maintain  a  solicitation  package  that  includes  the  requirements  and 
proposal  evaluation  criteria. 

For  task  orders  or  changes  against  an  existing  supplier  agreement,  ensure  the 
acquisition  project  has  documented  evaluation  criteria  against  which  to  evaluate  the 
proposed  changes  from  the  supplier. 

Define  the  proposal  content  that  the  suppliers  must  submit  with  their  response. 

Examples  include: 

Evidence  of  existing  organizational  processes  upon  which  the  project’s  processes  will 
be  based  and  the  commitment  to  execute  those  processes  from  project  inception 

Descriptions  in  the  proposed  documents  such  as  the  statement  of  work  (SOW), 
integrated  master  plan  (IMP),  integrated  master  schedule  (IMS),  and  software 
development  plan  (SDP)  of  the  processes,  tasks,  and  activities  characteristic  of  the 
proposed  development  approach 
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Description  of  how  the  proposed  approach  (e.g.,  SOW,  IMP,  IMS,  SDP  or  other 
documents)  demonstrates  a  commitment  to  execute  the  project  using  the  processes  and 
methods  proposed  from  project  inception.  Require  suppliers  to  provide  evidence  of  a 
mechanism  to  encourage  and  monitor  execution  of  organizational  processes  at  project 
start  up.  Require  suppliers  to  describe  measurements  that  provide  project  team 
visibility  into  the  supplier’s  process  adherence 

Description  of  how  the  proposed  approach  demonstrates  high  confidence  that  the  size 
and  complexity  of  the  development  and  integration  effort  is  understood,  the  effort  and 
schedule  necessaiy  to  develop  the  required  products  are  estimated  with  high 
confidence,  and  that  the  proposed  development  effort  is  compatible  with  and  can  be 
completed  within  the  proposed  funding  and  schedule 

Plans  appropriate  to  the  scope  and  content  of  the  project  (e.g.,  integrated 
management  plan,  systems  engineering  plan,  software  development  plan,  and  risk 
management  plan) 

Identification  of  the  measurements,  including  development  progress  measures,  to  be 
used  in  the  project  and  made  available  to  the  project  office 

A  description  of  the  supplier’s  planned  use  of  COTS  or  re-use  of previously  developed 
hardware  or  software  components,  including  non-deliverable  components  (This 
description  should  identify  any  limitations  of  data  rights  and  rationale  for  the 
supplier’s  confidence  that  the  levels  of  COTS  and  re-use  can  be  achieved.) 

An  approach  that  provides  visibility  of  development  task  progress  and  costs  at  a  level 
appropriate  for  the  type  of  supplier  agreement  and  commensurate  with  the  degree  of 
risk  related  to  the  acquisition 

Identification  of  the  work  to  be  performed  by  lower-level  suppliers 

Proposed  tasks  and  activities  to  support  product  verification,  validation,  and 
transition  to  operations  and  support 

Technical,  non-technical,  and  product  verification  requirements  to  be  satisfied  by  the 
supplier 

Deliverables  that  provide  the  acquisition  project  sufficient  data  to  evaluate  and 
analyze  the  acquired  products 

Requirements  to  ensure  that  the  supplier  supports  each  of  the  acquisition  project 's 
technical  review  and  validation  activities 

Requirements  for  the  supplier  to  establish  a  corrective  action  system  that  includes  a 
change  control  process  for  rework  and  reevaluation 

The  acquisition  organization  should  request  evidence  of  adherence  to  the  supplier 
organization ’s  mechanism  for  project  start  up  in  accordance  with  their  defined 
processes. 

1.3  Review  the  solicitation  package  with  stakeholders  to  ensure  that  the  approach  is 
realistic  and  can  reasonably  lead  to  the  acquisition  of  a  usable  product. 

To  ensure  objectivity  and  realism,  cost  and  schedule  estimates  should  be  reviewed  by 
individuals  independent  of  the  acquisition  project  team  and  supplier’s  team. 
Representatives  from  the  functional  or  “home  office”  organizations  within  the 
acquisition  organization,  such  as  finance  and  engineering,  can  support  these  efforts. 

1.4  Distribute  the  solicitation  package  to  potential  suppliers  for  their  response  and 
maintain  the  package  throughout  the  solicitation. 
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In  a  competitive  environment,  ensure  all  potential  suppliers  have  equal  access  and 
opportunity  to  provide  feedback  on  the  solicitation  package.  Provide  the  opportunity  for 
the  selected  suppliers  and  end  users  to  clarify  points  of  ambiguity  in  the  set  of  required 
capabilities  as  well  as  any  disconnects  or  concerns  with  the  proposed  solution.  In  a  sole 
source  or  change  order  environment,  make  sure  relevant  stakeholders  understand  the 
intent  of  the  new  effort  or  the  changes  before  placing  additional  work  on  the  supplier 
agreement. 


2.  Suppliers  are  selected  using  a  formal  evaluation. 

2. 1  Evaluate  proposed  solutions  according  to  documented  proposal  evaluation  criteria. 

The  criteria  are  used  to  evaluate  the  suppliers  ’  technical  approach  as  well  as  their 
management  practices,  sufficiency  of  plans,  process  capability  in  key  project  risk  areas, 
relevant  domain  experience,  cost,  schedule,  and  past  performance. 

2.2  Establish  and  maintain  negotiation  plans  to  use  in  completing  a  supplier  agreement. 

2.3  Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet  specified  requirements 
and  established  criteria 

3.  Supplier  agreements  are  established  and  maintained. 

3.1  Establish  and  maintain  a  mutual  understanding  of  the  agreement  with  selected 
suppliers  and  end  users  based  on  acquisition  needs  and  the  suppliers’  proposed 
approaches. 

As  points  of  clarification  and  ambiguities  continue  to  arise  after  supplier  agreement 
award,  ensure  the  mutual  understanding  is  revised  and  maintained  through  the  life  of  the 
project.  Ensure  that  the  supplier  makes  a  commitment  in  the  supplier  agreement  to 
execute  its  proposed  processes. 

3.2  Establish  and  maintain  the  supplier  agreement. 

The  acquisition  project  is  responsible  for  establishing  and  maintaining  the  ground  rules 
for  supplier  communication,  documenting  decisions,  and  conflict  resolution  through  the 
life  of  the  project.  The  acquisition  project  facilitates  these  activities  with  relevant  project 
stakeholders.  Specific  roles  and  responsibilities  of  relevant  project  stakeholders  for 
interaction  with  or  direction  of  the  suppliers  need  to  be  defined,  coordinated,  and 
adhered  to. 

After  the  supplier  agreement  is  awarded,  the  acquisition  project  should  verify  that  the 
supplier  is  effectively  executing  its  organization 's  processes. 

After  establishing  the  supplier  agreement,  the  acquirer  may  find  requirements  that  are  no 
longer  optimal  or  applicable  based  on  the  supplier’s  progress  or  environment  changes. 
Examples  include  the  availability  of  new  technology,  overly  burdensome  documentation, 
and  reporting  requirements.  Changes  to  supplier  agreements  may  also  occur  when  the 
supplier ’s  processes  or  products  fail  to  meet  agreed-to  criteria. 
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Agreement  Management  (AM) 


The  purpose  of  Agreement  Management  (AM)  is  to  ensure  that  the  supplier  and  the  acquirer  per¬ 
form  according  to  the  terms  of  the  supplier  agreement. 

The  supplier  agreement  is  the  basis  for  managing  the  relationship  with  the  supplier,  including 
resolving  issues.  It  defines  the  mechanisms  that  allow  the  acquirer  to  oversee  the  supplier ’s 
activities  and  evolving  products  and  to  verify  compliance  with  supplier  agreement  requirements. 

It  is  also  the  vehicle  for  a  mutual  understanding  between  the  acquirer  and  supplier.  When  the 
supplier’s  performance,  processes,  or  products  fail  to  satisfy  established  criteria  as  outlined  in 
the  supplier  agreement,  the  acquirer  may  take  corrective  action. 

1.  The  terms  of  the  supplier  agreement  are  met  by  both  the  acquirer  and  the  supplier. 

1 . 1  Perform  activities  with  the  supplier  as  specified  in  the  supplier  agreement. 

The  acquirer  and  supplier  establish  and  maintain  a  mutual  understanding  through 
effective,  timely,  and  appropriate  communication.  The  acquirer  should  clearly  identify 
and  prioritize  its  needs  and  expectations,  as  well  as  its  suppliers  ’  capabilities.  The 
acquirer  works  closely  with  suppliers  to  achieve  a  mutual  understanding  of  product 
requirements,  responsibilities,  and  processes  that  are  applied  to  achieve  project 
objectives. 

1.2  Select,  monitor,  and  analyze  supplier  processes. 

The  supplier ’s  plans  and  processes  are  used  as  the  basis  for  monitoring  its  activities.  The 
acquisition  project  is  responsible  for  ensuring  the  supplier’s  “as  implemented’’  processes 
address  the  needs  of  the  project.  The  acquisition  project  should  verify  that  the  supplier’s 
processes  are  executed  from  project  inception. 

If  not  performed  with  adequate  care, monitoring  can  at  one  extreme  be  invasive  and 
burdensome,  or  at  the  other  extreme  be  uninformative  and  ineffective.  The  acquirer 
decides  on  the  necessary  level  of  monitoring  depending  on  the  level  of  risk  if  the 
supplier ’s  process  is  not  performed  correctly.  Monitoring  activities  can  range  from 

reviewing  supplier-supplied  process  data  to  on-site  appraisals  of  the  supplier ’s 

2 

processes. 

1.2  Ensure  that  the  supplier  agreement  is  satisfied  before  accepting  the  acquired  product. 

This  practice  involves  ensuring  that  the  acquired  product  meets  all  requirements  and  that 
customers  concur  before  the  product  is  accepted.  The  acquirer  ensures  that  all 
acceptance  criteria  have  been  satisfied  and  that  all  discrepancies  have  been  corrected. 
Requirements  for  formal  deliverable  acceptance  and  how  to  address  non-conforming 
deliverables  are  usually  defined  in  the  supplier  agreement.  The  acquirer  should  be 
prepared  to  exercise  all  remedies  if  the  supplier  fails  to  perform. 

1.3  Manage  invoices  submitted  by  the  supplier. 


For  more  information  on  monitoring  supplier’s  processes,  see  Understanding  and  Leveraging  a  Supplier’s 
CM  Ml  Efforts:  A  Guidebook  for  Acquirers  (CMU/SEI-2007-TR-004).  Pittsburgh,  PA:  Software  Engineering  Insti¬ 
tute,  Carnegie  Mellon  University,  March  2007. 

http://www.sei.cmu.edu/publications/documents/07.reports/07tr004.html. 
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The  intent  of  this  practice  is  to  ensure  that  payment  terms  defined  in  the  supplier 
agreement  are  met  and  that  supplier  compensation  is  linked  to  supplier  progress,  as 
defined  in  the  supplier  agreement.  This  practice  covers  invoices  for  any  type  of  charge 
(e.g.,  one-time,  monthly,  deliverable-based,  pass-through).  It  covers  invoice  errors  or 
issues,  changes  to  invoices,  billing  errors,  and  withholding  disputed  charges  consistent 
with  the  terms  and  conditions  of  the  supplier  agreement.  The  acquirer  must  also  ensure 
that  appropriate  financial  and  invoice  management  controls  are  in  place. 
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Acquisition  Requirements  Development  (ARD) 


The  purpose  of  Acquisition  Requirements  Development  (ARD)  is  to  develop  and  analyze  cus¬ 
tomer  and  contractual  requirements. 

Acquisition  Requirements  Development  has  two  contexts.  The  first  context  is  the  amalgamation 
and  coordination  of  stakeholder  requirements  into  a  set  of  customer  requirements  that  defines  the 
scope  and  direction  of  the  acquisition.  The  second  context  is  the  refining  and  elaboration  of  the 
customer  requirements  into  contractual  requirements  that  become  the  basis  of  the  product  and 
product  component  requirements  derived  and  developed  by  the  supplier. 

The  requirements  included  in  the  solicitation  package  form  the  basis  for  evaluating  proposals  by 
suppliers  and  for  further  negotiations  with  suppliers  and  communication  with  the  customer.  The 
contractual  requirements  for  the  supplier  are  baselined  in  the  supplier  agreement. 

When  acquiring  services  instead  of  products,  the  same  requirements  process  is  used  to  define 
high-level  operational  needs  and  to  allocate  those  needs  to  lower  level  components  of  the  service 
to  ensure  the  resulting  service  meets  the  original  intent. 

1.  Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and  trans¬ 
lated  into  customer  requirements. 

1.1  Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces  for  all  phases  of  the 
product  lifecycle. 

This  practice  includes  review,  coordination,  and  formalization  of  top-level  operational 
needs  and  requirements  with  the  user. 

1.2  Transform  stakeholder  needs,  expectations,  constraints,  and  interfaces  into  prioritized 
customer  requirements. 

This  practice  includes  the  transformation  of  top  level  user  requirements  into  engineering- 
oriented  requirements  that  are  typically  included  in  a  solicitation.  Requirements  also 
include  non-functional  requirements  and  other  attributes  such  as  evolvabilitv, 
maintainability,  and  re-usability,  which  can  drive  the  definition  of  the  product 
requirements  and  architecture. 

This  practice  also  includes  defining  high-level  interface  requirements  in  a  system  of 
systems. 

2.  Customer  requirements  are  refined  and  elaborated  into  contractual  requirements. 

2. 1  Establish  and  maintain  contractual  requirements  that  are  based  on  customer 
requirements. 

Requirements  include  not  only  the  classical  functional  and  performance  requirements, 
but  also  interface  requirements,  whether  they  are  contained  in  separate  interface 
specifications  or  within  the  requirements  specifications. 

The  acquirer’s  level  of  involvement  in  allocating  system-level  requirements  to  lower  level 
subsystems  and  components  varies  depending  on  the  acquisition  environment. 

2.2  Allocate  contractual  requirements  to  supplier  deliverables. 
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As  each  level  of  requirements  is  defined,  there  is  an  iterative  process  of  allocation,  high- 
level  design,  and  requirements  definition  (for  the  next-lower  level).  Beyond  the  level  of 
the  architecture  at  which  this  responsibility  has  been  assigned  to  the  supplier,  it  is  the 
acquirer ’s  role  to  oversee  the  adequacy  of  the  supplier 's  process  and  the  resultant  flow- 
down  and  definition  of  lower  level  requirements. 

3.  Requirements  are  analyzed  and  validated. 

3.1  Establish  and  maintain  operational  concepts  and  associated  scenarios. 

Concepts  of  operations  documents  or  similar  documents  that  define  the  intended  usage 
concepts  and  environments  are  useful  in  developing  requirements  and  designs  that 
ultimately  satisfy  the  user’s  operational  needs. 

3.2  Analyze  requirements  to  ensure  that  they  are  necessary  and  sufficient. 

3.3  Analyze  requirements  to  balance  stakeholder  needs  and  constraints. 

Balance  stakeholder  needs  against  constraints  such  as  development  cost  and  schedule  or 
operational  and  support  considerations. 

3.4  Validate  requirements  to  ensure  the  resulting  product  performs  as  intended  in  the 
user’s  environment. 
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Acquisition  Technical  Management  (ATM) 


The  purpose  of  Acquisition  Technical  Management  (ATM)  is  to  evaluate  the  supplier’s  technical 
solution  and  to  manage  selected  interfaces  of  that  solution. 

Acquisition  technical  management  activities  involve  measuring  technical  progress  and  the 
effectiveness  of  plans  and  requirements.  Activities  include  those  associated  with  technical 
performance  measurement  and  the  conduct  of  technical  reviews.  A  structured  review  process 
should  demonstrate  and  confirm  completion  of  required  accomplishments  and  exit  criteria  as 
defined  in  project  planning  and  technical  plans  (e.g.,  the  systems  engineering  management  plan). 
Acquisition  technical  management  activities  discover  deficiencies  or  anomalies  that  often  result  in 
corrective  action. 

1.  Supplier  technical  solutions  are  evaluated  to  confirm  that  contractual  requirements 
continue  to  be  met. 

1 . 1  Select  supplier  technical  solutions  to  be  analyzed  and  analysis  methods  to  be  used. 

Depending  on  where  in  the  acquisition  lifecycle  the  highest  risks  occur,  the  acquirer 
selects  supplier  technical  solutions  for  analysis  to  reduce  those  risks.  Analysis  methods 
are  selected  based  on  the  type  of  technical  solution  being  analyzed. 

1.2  Analyze  selected  supplier  technical  solutions. 

The  acquirer  should  select  a  supplier ’s  design  to  analyze.  The  acquirer  explores  the 
adequacy  and  completeness  of  a  design  by  reviewing  product  representations  (e.g., 
prototypes,  simulations,  models,  scenarios,  and  storyboards)  and  obtaining  feedback 
about  them  from  relevant  stakeholders. 

The  acquirer  may  require  delivery  of  verification  results  from  the  supplier  of  the 
technical  solution,  as  applicable.  The  suppliers  may  conduct  verifications  in  an  iterative 
fashion,  concurrently  with  the  acquirer ’s  technical  analyses,  or  the  supplier  may  be 
required  to  conduct  follow-on  verifications  of  technical  solutions. 

1.3  Conduct  technical  reviews  with  the  supplier  as  defined  in  the  supplier  agreement. 

Technical  reviews  (i.e.,  architectural  evaluations)  are  performed  throughout  the  project 
lifecycle  to  gain  confidence  that  the  requirements,  architecture,  and  supplier  technical 
solutions  are  capable  of  guiding  a  development  that  results  in  a  product  or  sendee  that 
provides  the  required  capability.  This  activity  should  be  integrated  with  risk  management 
activities.  Mature  organizations  typically  perform  technical  reviews  using  different 
proven  techniques  depending  on  the  type  of  review.  These  organizations  broaden  the 
basis  of  the  review  to  include  other  stakeholder  needs,  expectations,  and  constraints. 

2.  Selected  interfaces  are  managed. 

2. 1  Select  interfaces  to  manage. 

The  interfaces  considered  for  selection  include  all  interfaces  with  other  products  and 
services  in  the  operations  and  support  environments  as  well  as  environments  for 
verification  and  validation  and  services  that  support  those  environments.  The  acquirer 
should  review  all  supplier  interface  data  for  completeness  to  substantiate  the  complete 
coverage  of  all  interfaces  when  making  the  selection. 

2.2  Manage  selected  interfaces. 
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Managing  interfaces  includes  the  maintenance  of  the  consistency  of  the  interfaces 
throughout  the  life  of  the  product  and  the  resolution  of  conflict,  noncompliance,  and 
change  issues.  In  a  system-of-systems  environment,  the  management  of  interfaces 
between  products  or  services  acquired  from  suppliers  and  other  systems  within  the 
system  of  systems  is  critical  to  the  success  of  the  project. 
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Acquisition  Verification  (AVER) 


The  purpose  of  Acquisition  Verification  is  to  ensure  that  selected  work  products  meet  their  speci¬ 
fied  requirements. 

Acquisition  verification  involves  ensuring  that  the  evolving  work  products  of  the  acquisition 
project  meet  their  specified  requirements.  The  acquisition  project  should  ensure  that  a  proper 
verification  environment  exists  and  that  it  selects  work  products  to  evaluate  based  on  documented 
criteria.  Peer  reviews  are  used  to  evaluate  work  products  developed  by  the  acquisition  project. 

The  acquisition  project  is  also  responsible  for  ensuring  that  the  supplier  uses  appropriate 
methods  to  verify  its  work  products.  In  this  context,  the  test  community  is  a  major  stakeholder, 
including  participation  in  up-front  planning  through  final-product  acceptance.  The  supplier 
and/or  the  test  community  may  perform  many  of  these  practices  with  the  acquisition  project 
facilitating  the  correction  of  deficiencies  or  enhancements  by  the  supplier  or  follow-on 
maintenance  organization.  It  is  important  that  the  acquirer  define  at  the  outset  the  degree  to 
which  verification  is  required  both  early  in  the  definition  of  the  project  and  later  when  the 
products  are  received. 

Verifications  of  the  evolving  products  by  the  supplier  are  routinely  conducted  throughout  the 
entire  supplier  agreement  performance  period  and  results  are  analyzed  to  determine  acceptability 
of  the  products  (see  the  Acquisition  Technical  management  and  Agreement  Management  process 
areas).  Acquisition  project  verification  activities  should  be  designed  to  reduce  interference  with 
activities  performed  by  the  supplier  and  test  communities  and  to  reduce  duplication  of  the 
verification  efforts. 

1.  Preparation  for  verification  is  conducted. 

1 . 1  Select  work  products  to  be  verified  and  verification  methods  to  be  used. 

Acquirer  work  products  are  selected  based  on  their  contribution  to  meeting  project 
objectives  and  requirements,  and  to  addressing  project  risks.  Peer  reviews  are  one  of  the 
methods  used  to  verify  work  products  produced  by  the  acquisition  project.  Other  methods 
should  be  selected  when  verifying  work  products  from  the  supplier.  Examples  of  these 
other  methods  include  demonstration,  inspection,  and  actual  testing. 

1.2  Establish  and  maintain  the  environment  needed  to  support  verification. 

The  acquisition  project  should  provide  an  adequate  environment  to  cany  out  its 
verification  activities. 

1.3  Establish  and  maintain  verification  procedures  and  criteria  for  the  selected  work 
products. 

2.  Peer  reviews  are  performed  on  selected  work  products. 

A  peer  review  is  a  method  for  conducting  verification  of  work  products  that  has  had  great 
success  in  detecting  defects,  especially  in  documents  for  requirements  and  design.  The 
acquisition  project  uses  peer  reviews  on  selected  products  (e.g.,  solicitation  documents, 
system  engineering  plans,  and  test  plans)  they  produce  internally  to  find  and  remove  defects 
and  to  ensure  compliance  to  acquisition  standards.  Many  work  products  produced  by  the 
acquisition  project  set  the  stage  for  the  project  success  and  are  critical  to  the  supplier 's 
performance.  The  supplier  typically  uses  peer  reviews  internally  on  selected  interim  work 
products  during  development,  but  the  acquirer  should  not  rely  solely  on  these  results. 
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2. 1  Prepare  for  peer  reviews  of  selected  work  products. 

2.2  Conduct  peer  reviews  of  selected  work  products  and  identify  issues  resulting  from 
these  reviews. 

2.3  Analyze  data  about  the  preparation,  conduct,  and  results  of  the  peer  reviews. 

3.  Selected  work  products  are  verified  against  their  specified  requirements. 

3.1  Perform  verification  on  selected  work  products. 

3.2  Analyze  results  of  all  verification  activities. 
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Acquisition  Validation  (AVAL) 


The  purpose  of  Acquisition  Validation  is  to  demonstrate  that  an  acquired  product  or  service  ful¬ 
fills  its  intended  use  when  placed  in  its  intended  environment. 

Acquisition  Validation  activities  can  be  applied  to  all  aspects  of  the  product  or  sendee  in  any  of 
its  intended  environments  such  as  operation,  training,  manufacturing,  maintenance,  and  support 
services.  The  methods  employed  to  accomplish  validation  can  be  applied  to  work  products  as  well 
as  to  the  product  and  product  components.  Work  products  (e.g.,  requirements,  designs,  and 
prototypes)  should  be  selected  for  validation  based  on  which  are  the  best  predictors  of  how  well 
the  delivered  end  product  and  product  components  will  satisfy  user  needs. 

Validation  involves  ensuring  that  the  evolving  acquisition  work  products  (e.g.,  RFPs,  SOWs,  and 
plans)  meet  the  acquisition  project ’s  needs.  Validation  activities  are  normally  performed  early 
and  continuously  throughout  the  acquisition  lifecycle.  The  acquirer  also  uses  validation  processes 
to  ensure  that  the  product  or  service  received  from  the  supplier  will  fulfill  its  intended  use.  In  this 
context,  the  test  community  is  a  major  stakeholder,  participating  in  up-front  planning  through 
final-product  acceptance.  The  supplier  and/or  the  test  community  may  perform  many  of  the 
validation  practices  with  the  acquisition  project  facilitating  the  correction  of  deficiencies  or 
enhancements  by  the  supplier  or  follow-on  maintenance  organization. 

Validation  involves  the  development  of  requirements  for  the  validation  approach,  including 
acceptance  criteria,  which  are  incorporated  into  both  the  solicitation  package  and  the  supplier 
agreement.  Validations  of  the  evolving  products  by  both  the  supplier  and  project  are  routinely 
conducted  throughout  the  entire  supplier  agreement  performance  period  and  results  are  analyzed 
to  determine  acceptability  of  the  products.  Project  validation  activities  should  be  designed  to 
reduce  interference  with  supplier  and  test  community-performed  activities  and  to  reduce  the 
duplication  of  validation  efforts.  Validation  processes  support  establishing  and  validating 
requirements.  See  the  Acquisition  Requirements  Development  process  area  for  more  information. 

1.  Preparation  for  validation  is  conducted. 

1 . 1  Select  products  and  product  components  to  be  validated  and  validation  methods  to  be 
used. 

It  is  important  that  the  acquirer  define  at  the  outset  the  degree  to  which  validation  is 
required  both  early  in  the  project  (e.g.,  requirements  validation  activities)  and  later  when 
the  end  products  are  received. 

1.2  Establish  and  maintain  the  environment  needed  to  support  validation. 

Plans  should  identify  adequate  resources  to  execute  validation  activities. 

1.3  Establish  and  maintain  procedures  and  criteria  for  validation. 

Validation  procedures  also  address  the  validation  of  requirements  and  the  acquired 
product  or  service  throughout  the  project  lifecycle.  Typically,  formal  acceptance  testing 
procedures  and  criteria  are  established  to  ensure  the  delivered  product  or  service  meets 
stakeholder  needs  before  it  is  deployed  in  the  intended  environment. 

2.  Selected  products  and  product  components  are  validated  to  ensure  they  are  suitable 

for  use  in  their  intended  operating  environment. 

2. 1  Perform  validation  on  selected  products  and  product  components. 
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Validation  activities  are  performed  by  the  acquirer,  the  supplier,  or  both  parties 
according  to  the  supplier  agreement. 

2.2  Analyze  results  of  validation  activities. 
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2.3  SUPPORT  PROCESS  AREAS 


The  support  process  areas  include  the  processes  and  tools  required  to  allow  projects  to  effectively 
apply  measurement,  control,  and  decision  techniques  to  manage  the  project. 
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Configuration  Management  (CM) 


The  purpose  of  Configuration  Management  is  to  establish  and  maintain  the  integrity  of  work 
products  using  configuration  identification,  configuration  control,  configuration  status  accounting, 
and  configuration  audits. 

Acquired  products  may  need  to  be  placed  under  configuration  management  by  both  the  supplier 
and  the  acquirer.  Provisions  for  conducting  configuration  management  should  be  established  in 
supplier  agreements.  Methods  to  ensure  that  data  are  complete  and  consistent  should  be 
established  and  maintained. 

1.  Baselines  of  identified  work  products  are  established. 

1 . 1  Identify  configuration  items,  components,  and  related  work  products  to  be  placed 
under  configuration  management. 

Acquisition  organizations  should  identify  and  categorize  risks  and  risk  sources  for  the 
project  initially  and  refine  those  risks  and  categories  over  time  (e.g.,  schedule,  cost, 
supplier  execution,  technology  readiness,  and  issues  outside  control  of  acquisition 
organization). 

1.2  Establish  and  maintain  a  configuration  management  and  change  management  system 
for  controlling  work  products. 

The  acquirer  considers  how  configuration  items  are  shared  between  the  acquirer  and 
supplier  as  well  as  among  relevant  stakeholders.  If  the  use  of  an  acquirer’s  configuration 
management  system  is  extended  to  a  supplier,  the  acquirer  must  exercise  security  and 
access  control  procedures.  In  many  cases,  leaving  acquired  configuration  items  in  the 
physical  possession  of  the  supplier  and  having  access  to  supplier  deliverables  is  a  viable 
alternative.  The  supplier  agreement  specifies  appropriate  acquirer  rights  to  supplier 
deliverables  in  addition  to  requirements  for  delivery  or  access.  Supplier  work  products, 
whenever  they  are  delivered  to  the  acquirer,  are  presented  in  accordance  with  accepted 
standards  to  ensure  usability  by  the  acquirer. 

1.3  Create  or  release  baselines  for  internal  use  and  for  delivery  to  the  customer. 

The  acquirer  reviews  and  approves  the  release  of  product  baselines  created  by  the 
supplier.  The  acquirer  creates  baselines  for  acquirer  work  products  that  describe  the 
project,  requirements,  funding,  schedule,  and  performance  measures  and  makes  a 
commitment  to  manage  the  project  to  those  baselines. 

2.  Changes  to  the  work  products  under  configuration  management  are  tracked  and 

controlled. 

2. 1  Track  change  requests  for  configuration  items. 

Change  requests  can  be  initiated  either  by  the  acquirer  or  supplier.  Changes  that  impact 
acquirer  work  products  and  supplier  deliverables  as  defined  in  the  supplier  agreement 
are  handled  through  the  acquirer 's  configuration  management  process. 

2.2  Control  changes  to  configuration  items. 


32  |  CMU/SEI-2008-TR-010 


The  acquirer  decides  which  configuration  items  require  version  control  or  more  stringent 
levels  of  configuration  control  and  establishes  mechanisms  to  ensure  configuration  items 
are  controlled.  Although  the  supplier  may  manage  configuration  items  on  the  acquirer’s 
behalf,  the  acquirer  is  responsible  for  approval  and  control  of  changes  to  these 
configuration  items. 

3.  Integrity  of  baselines  is  established  and  maintained. 

3.1  Establish  and  maintain  records  describing  configuration  items. 

3.2  Perform  configuration  audits  to  maintain  the  integrity  of  configuration  baselines. 
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Decision  Analysis  and  Resolution  (DAR) 


The  purpose  of  Decision  Analysis  and  Resolution  is  to  analyze  possible  decisions  using  a  formal 
evaluation  process  that  evaluates  identified  alternatives  against  established  criteria. 

A  repeatable,  criteria-based  decision-making  process  is  especially  important  both  while  making 
the  critical  decisions  that  define  and  guide  the  acquisition  process  itself  and  later  when  critical 
decisions  are  made  with  the  selected  supplier.  The  establishment  of  a  formal  process  for  decision 
making  provides  the  acquisition  project  with  documentation  of  the  decision  rationale.  Such 
documentation  allows  the  criteria  for  critical  decisions  to  be  revisited  when  changes  impact 
project  requirements  or  other  critical  project  parameters. 

1.  Decisions  are  based  on  an  evaluation  of  alternatives  using  established  criteria. 

1 . 1  Establish  and  maintain  guidelines  to  determine  which  issues  are  subject  to  a  formal 
evaluation  process. 

Not  every  decision  is  significant  enough  to  require  a  formal  evaluation  process.  The 
choice  between  the  trivial  and  the  truly  important  may  be  unclear  without  explicit 
guidance.  The  significance  of  a  particular  decision  is  dependent  on  the  project  and 
circumstances  and  is  determined  by  the  established  guidelines. 

1.2  Establish  and  maintain  criteria  for  evaluating  alternatives,  and  the  relative  ranking  of 
these  criteria. 

Regular  use  of  decision-making  criteria,  even  for  less  significant  decisions,  can  be 
extremely  helpful  in  creating  a  practice  for  disciplined  decision  making.  Practiced 
evaluators  have  demonstrated  that  defined  criteria  and  weighting  can  be  a  significant 
contributor  to  the  speed  and  consensus  level  of  a  decision. 

1.3  Identify  alternative  solutions  to  address  issues. 

A  wider  range  of  alternatives  can  surface  by  soliciting  as  many  stakeholders  as  is 
practical  for  input.  Input  from  stakeholders  with  diverse  skills  and  backgrounds  can  help 
teams  identify  and  address  assumptions,  constraints,  and  biases.  Brainstorming  sessions 
with  support  from  the  stakeholder  may  stimulate  innovative  alternatives  through  rapid 
interaction  and  feedback. 

1.4  Select  evaluation  methods. 

Suppliers  competing  to  develop  a  technical  solution  for  the  acquirer  may  be  directly 
evaluated  in  a  final  competition  that  involves  a  performance  or  functional  demonstration 
of  proposed  solutions. 

1.5  Evaluate  alternative  solutions  using  established  criteria  and  methods. 

1.6  Select  solutions  from  alternatives  based  on  evaluation  criteria. 

Document  the  results  of  the  evaluation  for  future  reference. 
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Measurement  and  Analysis  (MA) 


The  purpose  of  Measurement  and  Analysis  is  to  develop  and  sustain  a  measurement  capability 
used  to  support  management  information  needs. 

The  acquisition  project  has  needs  for  information  to  help  determine  the  status  of  its  activities 
throughout  the  acquisition  lifecycle,  the  supplier 's  activities  per  requirements  in  the  supplier 
agreement,  and  the  status  of  the  evolving  products  acquired.  In  acquisition  projects  in  which 
multiple  products  are  acquired  to  deliver  a  capability  to  the  end  user,  or  in  which  there  are 
teaming  relationships  with  other  acquisition  projects  to  acquire  joint  capabilities,  additional 
information  needs  may  be  identified  to  ensure  programmatic,  technical,  and  operational 
interoperability  objectives  for  the  product  are  identified,  measured,  and  achieved. 

1.  Measurement  objectives  and  activities  are  aligned  with  identified  information  needs 
and  objectives. 

Not  all  measurements  are  valuable.  Those  measurements  that  address  the  needs  and 
objectives  of  the  acquisition  project  are  the  most  valuable.  It  is  best  to  identify  the 
measures  that  focus  on  the  objectives,  rather  than  measures  that  are  easily  obtained  but 
have  questionable  value. 

1.1  Establish  and  maintain  measurement  objectives  derived  from  identified  information 
needs  and  objectives. 

Identify  the  information  needed  to  keep  the  acquisition  on  track  to  a  successful 
conclusion.  Establish  measurement  objectives  and  measurement  criteria  needed  to 
provide  this  information. 

1.2  Specify  measures  to  address  measurement  objectives. 

In  most  cases,  supplier  measures  are  the  primary  source  of  data,  especially  with  regard 
to  the  development  of  the  acquired  product  or  service.  For  instance,  measurement  and 
analysis  of  the  product  or  product  components  provided  by  a  supplier  through  technical 
performance  measures  is  essential  for  effective  management.  Technical  performance 
measures  are  precisely  defined  measures  based  on  a  product  requirement,  product 
capability,  or  some  combination  of  requirements  and  capabilities. 

1.3  Specify  how  measurement  data  is  obtained  and  stored. 

The  supplier  agreement  specifies  the  measurement  data  the  supplier  must  provide  to  the 
acquirer,  the  format  in  which  data  must  be  provided  to  the  acquirer,  how  the  data  must 
be  collected  and  stored  by  the  supplier  (e.g.,  retention  period  of  data),  how  and  how  often 
data  must  be  transferred  to  the  acquirer,  and  who  has  access  to  data.  Some  supplier  data 
may  be  considered  proprietary  by  the  supplier  and  may  need  to  be  protected  as  such  by 
the  acquirer.  Some  acquirer  measurement  data  (e.g.,  total  project  cost  data)  may  be 
proprietary  and  should  not  be  shared  with  suppliers.  An  acquirer  must  plan  for  the 
collection,  storage,  and  access  control  of  sensitive  data. 

1.4  Specify  how  measurement  data  are  analyzed  and  communicated. 

The  supplier  agreement  defines  the  data  analysis  and  the  definition  and  examples  of 
measures  the  supplier  must  provide  to  the  acquirer. 
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2.  Measurement  results,  which  address  identified  information  needs  and  objectives, 
are  provided. 

2. 1  Obtain  specified  measurement  data. 

2.2  Analyze  and  interpret  measurement  data. 

2.3  Manage  and  store  measurement  data,  measurement  specifications,  and  analysis 
results. 

2.4  Communicate  results  of  measurement  and  analysis  activities  to  all  relevant 
stakeholders. 
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Process  and  Product  Quality  Assurance  (PPQA) 


The  purpose  of  Process  and  Product  Quality  Assurance  (PPQA)  is  to  provide  staff  and  manage¬ 
ment  with  objective  insight  into  processes  and  associated  work  products. 

The  acquirer  evaluates  critical  acquirer  work  products,  acquirer  processes,  results  of  supplier 
process  quality  assurance,  and  supplier  deliverables.  For  example,  process  and  product  quality 
assurance  process  ensures  that  the  solicitation  package  was  developed  using  standard  processes 
agreed  on  by  the  acquirer  and  supplier  and  that  the  package  conforms  to  all  applicable  policies. 
The  acquirer  may  review  results  of  supplier  quality  assurance  activities  for  selected  supplier 
processes  to  ensure  that  the  supplier  is  following  its  own  processes. 

1.  Adherence  of  the  performed  process  and  associated  work  products  and  services  to 

applicable  process  descriptions,  standards,  and  procedures  is  objectively  evaluated. 

1.1  Objectively  evaluate  designated  performed  processes  against  applicable  process 
descriptions,  standards,  and  procedures. 

1.2  Objectively  evaluate  designated  work  products  and  services  against  applicable 
process  descriptions,  standards,  and  procedures. 

In  addition  to  objectively  evaluating  critical  acquirer  work  products,  the  acquirer  uses 
objective  acceptance  criteria  to  evaluate  supplier  deliverables  throughout  the  project 
lifecycle.  The  acquirer’s  acceptance  criteria  for  supplier  deliverables  are  consistent  with 
project  objectives  and  sufficient  to  allow  the  supplier  to  satisfactorily  demonstrate  that 
the  product  conforms  to  requirements  in  the  supplier  agreement. 

2.  Noncompliance  issues  are  objectively  tracked  and  communicated,  and  resolution  is 

ensured. 

2. 1  Communicate  quality  issues  and  ensure  the  resolution  of  noncompliance  issues  with 
the  staff  and  managers. 

2.2  Establish  and  maintain  records  of  quality  assurance  activities. 
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3  Generic  Practices 


Generic  practices  are  practices  that  should  be  included  in  every  process  area,  in  addition  to  the 
specific  practices  that  appear  in  each  process  area  description.  Generic  practices  improve  the 
power  of  a  process  by  ensuring  that  the  specific  practices  are  executed  and  that  there  is  appropri¬ 
ate  planning  of  the  process  to  ensure  that  it  is  feasible  and  well  supported  and  that  stakeholders 
are  properly  involved. 

In  this  section,  practices  are  denoted  by  bold-faced  text  and  followed  by  a  brief  explanation.  The 
last  two  generic  practices  documented  in  this  section  ensure  that  the  performance  of  each  process 
and  the  lessons  learned  are  saved  and  that  this  knowledge  is  used  to  establish  new  projects  or  to 
improve  the  performance  of  an  existing  project.  The  12  generic  practices  listed  here  correspond  to 
the  1 0  generic  practices  under  generic  goal  2  and  the  two  generic  practices  under  generic  goal  3  in 
the  CMMI-ACQ  model. 

1.  Establish  and  maintain  an  organizational  policy  for  planning  and  performing  the 
process. 

This  generic  practice  defines  the  organizational  expectations  for  the  process  and  makes  these  ex¬ 
pectations  visible  to  those  in  the  organization  who  are  affected.  In  general,  senior  management  is 
responsible  for  establishing  and  communicating  guiding  principles,  direction,  and  expectations  for 
the  organization. 

Not  all  direction  from  senior  management  will  bear  the  label  “policy.”  The  existence  of  appropri¬ 
ate  organizational  direction  is  the  expectation  of  this  generic  practice,  regardless  of  what  it  is 
called  or  how  it  is  imparted. 

This  policy  establishes  organizational  expectations  for  planning  and  performing  the  process,  in¬ 
cluding  not  only  the  elements  of  the  process  addressed  directly  by  the  acquirer,  but  also  the  inter¬ 
actions  of  the  acquirer  with  suppliers. 

2.  Establish  and  maintain  the  plan  for  performing  the  process. 

The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to  perform  the  process  and 
achieve  the  established  objectives,  to  prepare  a  plan  for  performing  the  process,  to  prepare  a  proc¬ 
ess  description,  and  to  get  agreement  on  the  plan  from  relevant  stakeholders. 

Planning  a  process  applies  to  all  process  areas  including  Project  Planning.  The  process  for  plan¬ 
ning  the  project  requires  planning  (e.g.,  resource,  duration)  just  like  any  other  activity. 

The  objectives  for  the  process  may  be  derived  from  other  plans  (e.g.,  project  plans).  Included  are 
objectives  for  the  specific  situation,  including  quality,  cost,  and  schedule  objectives.  For  example, 
an  objective  might  be  to  reduce  the  cost  of  performing  a  process  for  an  implementation  over  its 
previous  implementation. 

Establishing  a  plan  includes  documenting  the  plan  and  a  process  description.  Maintaining  the  plan 
includes  updating  it  as  necessary  in  response  to  either  corrective  actions  or  to  changes  in  process 
requirements  and  objectives. 
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The  plan  for  performing  the  process  typically  includes  the  following  elements: 

•  Process  description 

•  Standards  and  requirements  for  the  work  products  and  services  of  the  process 

•  Objectives  for  the  performance  of  the  process  (e.g.,  quality,  time  scale,  cycle  time,  and  re¬ 
source  usage) 

•  Dependencies  among  activities,  work  products,  and  services  of  the  process 

•  Resources  (including  funding,  people,  and  tools)  needed  to  perform  the  process 

•  Assignment  of  responsibility  and  authority 

•  Training  needed  for  performing  and  supporting  the  process 

•  Work  products  to  be  controlled  and  the  level  of  control  for  each  item 

•  Measurement  requirements  to  provide  insight  into  the  performance  of  the  process,  its  work 
products,  and  its  services 

•  Involvement  of  identified  stakeholders 

•  Activities  for  monitoring  and  controlling  the  process 

•  Objective  evaluation  activities  for  the  process 

•  Management  review  activities  for  the  process  and  the  work  products 

3.  Provide  adequate  resources  for  performing  the  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 

This  generic  practice  ensures  that  resources  necessary  to  perform  the  process  as  defined  by  the 
plan  are  available  when  they  are  needed.  Resources  include  adequate  funding,  appropriate  physi¬ 
cal  facilities,  skilled  people,  and  appropriate  tools. 

The  interpretation  of  the  tenn  adequate  depends  on  many  factors  and  can  change  over  time.  In¬ 
adequate  resources  may  be  addressed  by  increasing  resources  or  by  removing  requirements,  con¬ 
straints,  and  commitments. 

4.  Assign  responsibility  and  authority  for  performing  the  process,  developing  the 
work  products,  and  providing  the  services  of  the  process. 

This  generic  practice  ensures  that  there  is  accountability  for  performing  the  process  and  achieving 
the  specified  results  throughout  the  life  of  the  process.  The  people  assigned  must  have  the  appro¬ 
priate  authority  to  perform  their  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in  living  documents,  such  as  the 
plan  for  perfonning  the  process.  Dynamic  assignment  of  responsibility  is  another  legitimate  way 
to  perform  this  generic  practice,  as  long  as  the  assignment  and  acceptance  of  responsibility  are 
ensured  throughout  the  life  of  the  process. 

5.  Train  the  people  performing  or  supporting  the  process  as  needed. 

This  generic  practice  ensures  that  the  people  have  the  necessary  skills  and  expertise  to  perform  or 
support  the  process. 
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Training  supports  the  successful  performance  of  the  process  by  establishing  a  common  under¬ 
standing  of  the  process  and  by  imparting  the  skills  and  knowledge  needed  to  perform  the  process. 

6.  Place  designated  work  products  of  the  process  under  appropriate  levels  of  control. 

This  generic  practice  establishes  and  maintains  the  integrity  of  the  designated  work  products  of 
the  process  (or  their  descriptions)  throughout  their  useful  life. 

Designated  work  products  are  identified  in  the  plan  for  performing  the  process,  along  with  a  spe¬ 
cification  of  the  appropriate  level  of  control. 

7.  Identify  and  involve  the  relevant  stakeholders  of  the  process  as  planned. 

This  generic  practice  establishes  and  maintains  the  expected  involvement  of  stakeholders  during 
the  execution  of  the  process. 

To  plan  stakeholder  involvement,  ensure  that  sufficient  stakeholder  interaction  necessary  to  ac¬ 
complish  the  process  occurs,  while  avoiding  excessive  numbers  of  stakeholders  that  could  impede 
process  execution. 

8.  Monitor  and  control  the  process  against  the  plan  for  performing  the  process  and 
take  appropriate  corrective  action. 

The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day  monitoring  and  controlling 
of  the  process.  Appropriate  visibility  into  the  process  is  maintained  so  that  appropriate  corrective 
action  can  be  taken  when  necessary.  Monitoring  and  controlling  the  process  involves  measuring 
appropriate  attributes  of  the  process  or  work  products  produced  by  the  process. 

9.  Objectively  evaluate  adherence  of  the  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

This  generic  practice  provides  credible  assurance  that  the  process  is  implemented  as  planned  and 
adheres  to  its  process  description,  standards,  and  procedures.  This  generic  practice  is  imple¬ 
mented,  in  part,  by  evaluating  selected  work  products  of  the  process. 

10.  Review  the  activities,  status,  and  results  of  the  process  with  higher  level 
management  and  resolve  issues. 

This  generic  practice  provides  higher  level  management  with  the  appropriate  visibility  into  the 
process. 

Higher  level  management  includes  those  levels  of  management  in  the  organization  above  the  im¬ 
mediate  level  of  management  responsible  for  the  process.  In  particular,  higher  level  management 
includes  senior  management.  These  reviews  are  for  managers  who  provide  the  policy  and  overall 
guidance  for  the  process,  and  not  for  those  who  perform  the  direct  day-to-day  monitoring  and 
controlling  of  the  process. 

The  following  two  generic  practices  form  the  basis  for  propagating  good  practice  to  future 
acquisition  projects.  These  practices  facilitate  process  definition  and  identify  process  benefits  that 
encourage  adoption  of  best  practices  on  new  projects. 
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A  defined  process  is  tailored  from  the  organization’s  set  of  standard  processes  according  to  the 
organization’s  tailoring  guidelines  and  contributes  work  products,  measures,  and  other  process- 
improvement  information  to  the  organizational  process  assets. 

These  two  generic  practices  activate  a  process  improvement  cycle.  The  organization  maintains  a 
process  asset  library  and  standard  process  that  can  be  drawn  upon  by  a  project  to  create  its  proc¬ 
esses.  In  turn,  the  project  provides  information  about  the  performance  of  its  process  to  the  organi¬ 
zation’s  process  asset  library,  which  is  used  to  improve  and  extend  the  standard  processes. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the  defined  process,  are  estab¬ 
lished  and  improved  over  time.  Standard  processes  describe  the  fundamental  process  elements 
that  are  expected  in  the  defined  processes.  Standard  processes  also  describe  the  relationships  (e.g., 
the  ordering  and  interfaces)  between  these  process  elements.  The  organization-level  infrastructure 
to  support  current  and  future  use  of  the  organization’s  set  of  standard  processes  is  established  and 
improved  over  time. 

11.  Establish  and  maintain  the  description  of  a  defined  process. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a  description  of  the  process  that  is 
tailored  from  the  organization’s  set  of  standard  processes  to  address  the  needs  of  a  specific  situa¬ 
tion.  The  organization  should  have  standard  processes  that  cover  the  process  area  and  have  guide¬ 
lines  for  tailoring  these  standard  processes  to  meet  the  needs  of  a  project  or  organizational  func¬ 
tion.  With  a  defined  process,  variability  in  how  the  processes  are  performed  across  the 
organization  is  reduced  and  process  assets,  data,  and  learning  can  be  effectively  shared. 

12.  Collect  work  products,  measures,  measurement  results,  and  improvement 
information  derived  from  planning  and  performing  the  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes  and  process  assets. 

This  generic  practice  collects  information  and  artifacts  derived  from  planning  and  performing  the 
process.  This  generic  practice  is  performed  so  that  the  information  and  artifacts  can  be  included  in 
organizational  process  assets  and  made  available  to  those  who  are  (or  who  will  be)  planning  and 
performing  the  same  or  similar  processes.  The  information  and  artifacts  are  stored  in  the  organiza¬ 
tion’s  measurement  repository  and  the  organization’s  process  asset  library. 
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Appendix:  Implementation  Questions 


The  questions  included  in  this  appendix  will  help  you,  as  an  acquisition  project  manager,  imple¬ 
ment  your  processes.  The  questions  help  you  verify  that  best  practices  are  being  employed  and 
provide  a  means  of  gathering  background  information  necessary  to  determine  if  the  products  or 
services  being  acquired  will  meet  the  operational  needs  of  your  organization. 

The  questions  in  the  tables  below  were  designed  to  facilitate  review  and  improvement  of  the  proc¬ 
esses  in  your  acquisition  organization.  They  address  whether  or  not  strategy  development,  plan¬ 
ning,  and  estimating  activities  occur.  In  large  part,  these  early  activities  determine  the  success  of 
an  acquisition  process  from  the  outset.  The  questions  also  focus  on  risk  identification,  manage¬ 
ment  practices,  capabilities  definition  and  requirements  generation,  and  the  existence  of  repeat- 
able  processes  that  enable  organizations  to  institutionalize  best  practices.  For  each  question  in  the 
left-hand  column,  the  relevant  process  areas,  described  in  detail  in  Section  2,  are  listed  in  the 
right-hand  column. 


1.  Processes  in  General 

Questions 

CMMI-ACQ  Process  Areas 

a.  What  are  the  content  and  source  of  your  acquisi¬ 
tion  processes? 

Project  Planning,  Integrated  Project 
Management 

b.  What  mechanisms  do  you  use  to  monitor,  control, 
and  improve  your  acquisition  processes? 

Project  Monitoring  and  Control,  Mea¬ 
surement  and  Analysis,  Process  and 
Product  Quality  Assurance 

c.  How  do  you  know  that  your  project  is  adhering  to 
your  acquisition  processes? 

Project  Monitoring  and  Control,  Proc¬ 
ess  and  Product  Quality  Assurance 

2.  User  Requirements 

Questions 

CMMI-ACQ  Process  Areas 

a.  Is  there  a  process  in  place  to  define,  verify,  and 
validate  customer  and  contractual  requirements? 

Acquisition  Requirements  Develop¬ 
ment 

b.  How  do  you  manage  users’  involvement  in  the  re¬ 
quirements  process? 

Project  Planning,  Integrated  Project 
Management,  Requirements  Man¬ 
agement,  Acquisition  Requirements 
Development 

c.  How  do  you  ensure  a  clear  understanding  of  user 
needs  by  relevant  stakeholders? 

Requirements  Management,  Acquisi¬ 
tion  Requirements  Development,  In¬ 
tegrated  Project  Management 

d.  What  role  does  your  organization  play  in  estab¬ 
lishing  the  project  requirements? 

Acquisition  Requirements  Develop¬ 
ment,  Requirements  Management, 
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e.  What  is  your  strategy  for  keeping  up  with  the 
evolving  operational  environment  (e.g.,  threat, 
concept  of  operations,  and  technology  readi¬ 
ness)? 

Integrated  Project  Management,  Re¬ 
quirements  Management 

3.  Acquisition  Strategy 

Questions 

CMMI-ACQ  Process  Areas 

a.  How  did  you  determine  the  most  appropriate  ac¬ 
quisition  strategy  for  this  acquisition? 

Project  Planning,  Decision  Analysis 
and  Resolution,  Risk  Management 

b.  How  does  your  selected  acquisition  strategy  miti¬ 
gate  the  risks  you  have  identified? 

Project  Planning,  Risk  Management 

c.  Which  stakeholders  were  involved  in  establishing 
the  acquisition  strategy? 

Project  Planning,  Integrated  Project 
Management 

4.  Acquisition  Planning 

Questions 

CMMI-ACQ  Process  Areas 

a.  How  do  your  acquisition  plans  reflect  and  imple¬ 
ment  the  acquisition  strategy? 

Project  Planning,  Integrated  Project 
Management,  Decision  Analysis  and 
Resolution 

b.  How  do  you  determine  and  document  the  scope 
of  the  project,  including  acquisition  project  activi¬ 
ties,  supplier  activities,  and  other  related  activities 
(operational  testing,  user  activities,  etc.)? 

Project  Planning,  Solicitation  and 
Supplier  Agreement  Development 

c.  How  do  you  determine  the  magnitude  of  the  de¬ 
velopment  effort? 

Project  Planning 

d.  How  do  you  determine  resource  needs  for  each 
element  of  the  project? 

Project  Planning 

e.  How  do  you  determine  the  critical  path? 

Project  Planning,  Integrated  Project 
Management 

f.  How  are  plans  coordinated  with  relevant  stake¬ 
holders  at  both  the  management  and  working  lev¬ 
els? 

Project  Planning,  Integrated  Project 
Management 

g.  How  do  you  ensure  that  you  have  adequate  staff 
with  the  necessary  experience  and  training  to  ex¬ 
ecute  your  plans? 

Project  Planning 

h.  How  do  you  ensure  that  the  supplier  has  the  re¬ 
sources  and  tools  needed  to  complete  the  pro¬ 
ject? 

Project  Planning,  Solicitation  and 
Supplier  Agreement  Development, 
Agreement  Management 
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i.  How  do  you  ensure  that  the  supplier  has  the  do¬ 
main  experience  and  process  capability  needed  to 
complete  the  project? 

Project  Planning,  Solicitation  and 
Supplier  Agreement  Development, 
Agreement  Management 

5.  Cost,  Schedule,  and  Performance  Baselines 

Questions 

CMMI-ACQ  Process  Areas 

a.  How  do  you  ensure  that  the  cost,  schedule,  and 
performance  baselines  are  integrated,  realistic 
and  executable? 

Project  Planning,  Integrated  Project 
Management 

b.  What  provisions  do  you  make  for  independent  re¬ 
views  of  your  cost,  schedule,  and  performance 
baselines? 

Project  Planning,  Integrated  Project 
Management,  Acquisition  Require¬ 
ments  Development,  Requirements 
Management 

c.  How  do  you  ensure  that  all  the  lifecycle  costs  are 
included  in  the  baselines  (e.g.,  testing,  training, 
sustainment,  and  support)? 

Project  Planning,  Integrated  Project 
Management, 

d.  How  do  you  plan  to  track  cost,  schedule,  and  per¬ 
formance  of  the  project  throughout  its  lifecycle? 

Project  Monitoring  and  Control, 
Measurement  and  Analysis 

e.  How  do  you  accommodate  risks  and  engineering 
changes  in  your  baselines? 

Project  Planning,  Risk  Manage¬ 
ment,  Requirements  Management 

f.  How  do  you  manage  changes  to  baselines? 

Configuration  Management,  Project 
Monitoring  and  Control,  Require¬ 
ments  Management 

g.  How  do  you  evaluate  the  impact  of  changes  in 
cost  and  schedule  on  supplier’s  development  ef¬ 
forts? 

Project  Monitoring  and  Control,  So¬ 
licitation  and  Supplier  Agreement 
Development,  Requirements  Man¬ 
agement 

6.  Risk  Identification  and  Management 

Questions 

CMMI-ACQ  Process  Areas 

a.  How  do  you  identify  project  risks? 

Project  Planning,  Risk  Management 

b.  How  do  you  identify  risks  related  to  your  acquisi¬ 
tion  strategy  and  plans? 

Project  Planning,  Risk  Management 

c.  How  do  you  identify  risks  associated  with  cost 
and  schedule? 

Project  Planning,  Integrated  Project 
Management,  Risk  Management 

d.  How  do  you  ensure  that  you  understand  the  cost 
risk  of  obtaining  the  required  capability? 

Project  Planning,  Risk  Manage¬ 
ment,  Requirements  Development 
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e.  How  do  you  identify  risks  related  to  supplier  exe¬ 
cution? 

Project  Planning,  Risk  Manage¬ 
ment,  Solicitation  and  Supplier 
Agreement  Development 

f.  How  do  you  identify  risks  that  are  outside  your 
control? 

Project  Planning,  Integrated  Project 
Management,  Risk  Management 

g.  How  do  you  assess  the  likelihood  and  conse¬ 
quence  of  project  risks? 

Risk  Management 

h.  How  do  you  monitor  mitigation  efforts  for  identified 
risks? 

Risk  Management 

i.  Which  risk  management  tool(s)  do  you  employ? 

Project  Planning,  Risk  Management 

j.  Who  is  involved  in  project  risk  assessment  (e.g., 
users,  the  supplier,  and  independent  subject  mat¬ 
ter  experts)? 

Integrated  Project  Management, 

Risk  Management 

k.  How  do  you  build  in  sufficient  reserves  for  risk  mi¬ 
tigation  and  absorbing  the  impact  of  realized 
risks? 

Project  Planning,  Risk  Management 

7.  Supplier  Monitoring 

Questions 

CMMI-ACQ  Process  Areas 

a.  How  do  you  assess  the  mechanisms  the  supplier 
uses  to  encourage  execution  of  their  organiza¬ 
tion’s  processes  from  the  beginning  of  the  pro¬ 
ject? 

Agreement  Management,  Acquisi¬ 
tion  Technical  Management,  Risk 
Management 

b.  Is  there  a  process  in  place  to  define,  verify,  and 
validate  requirements  and  architectures  for  the 
product? 

Acquisition  Requirements  Deve¬ 
lopment,  Acquisition  Technical 
Management 

c.  How  will  the  status  of  development  be  monitored? 

Project  Monitoring  and  Control, 
Measurement  and  Analysis,  Agree¬ 
ment  Management 

d.  How  will  the  supplier  demonstrate  the  perform¬ 
ance  and  stability  of  their  development  environ¬ 
ment  and  tools? 

Agreement  Management 
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8.  Nondevelopmental  Items 

Questions 

CMMI-ACQ  Process  Areas 

a.  What  is  your  strategy  for  incorporating  nondevel¬ 
opmental  products  (e.g.,  commercial  off-the-shelf 
[COTS],  government  off-the-shelf  [GOTS],  reuse, 
and  product  lines)  into  the  project? 

Project  Planning,  Decision  Analysis 
and  Resolution,  Acquisition  Re¬ 
quirements  Development 

b.  What  percentage  of  the  software  is  planned  to  be 
nondevelopmental? 

Project  Planning,  Measurement  and 
Analysis 

c.  How  do  you  determine  that  you  can  achieve  the 
planned  percentage  of  nondevelopmental  soft¬ 
ware  use  on  this  project? 

Project  Planning,  Risk  Manage¬ 
ment,  Verification,  Validation,  Deci¬ 
sion  Analysis  and  Resolution 

d.  How  do  you  determine  that  the  planned  nonde¬ 
velopmental  products  will  provide  the  required 
functionality  and  performance? 

Measurement  and  Analysis,  Re¬ 
quirements  Development,  Verifica¬ 
tion,  Validation,  Decision  Analysis 
and  Resolution 

e.  How  do  you  determine  that  the  interfaces  for  non¬ 
developmental  products  are  defined  and  agreed 
to  by  relevant  stakeholders? 

Acquisition  Technical  Management 

f.  How  do  you  account  for  the  effort  required  to  test 
and  integrate  nondevelopmental  products? 

Acquisition  Requirements  Develop¬ 
ment,  Acquisition  Technical  Mana¬ 
gement,  Validation 
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This  primer  can  also  be  used  by  acquisition  organizations  that  manage  several  related  acquisition  projects  (e.g.,  product  centers,  acquisition 
commands)  to  establish  an  acquisition  process  improvement  program.  However,  organizations  at  that  level  should  consider  using  the  CMMI- 
ACQ  model  instead  because  it  includes  organizational  process  management  practices. _ 
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